DataMapper - migration from 0.9.x to 0.10.x

Finally got some time to put here some notes for migrating DM from 0.9 to 0.10.

1. Errors. (That means you must fix)
  1.1 options[:default] must not be nil
property :customer_address_id, Integer #, :default => nil
  1.2 options :nullabe are unknown
property :deleted, Boolean, :field => 'deleteflag', :default => false #, :nullable => false
  1.3 +options[:order]+ entry "po.closed_date.desc" does not map to a property in PurchaseOrderLineItem
order_by = [DataMapper::Query::Direction.new(PurchaseOrder.properties[:closed_date], :desc)]
result = PurchaseOrderLineItem.first(:deleted => false, :cb3_id => cb3_id, 'po.deleted.eql' => false, 'po.completed.eql' => 'yes', :order => order_by)
  1.4 For composite keys
(e.g. when you do a migrate!)
property :user_id, Integer, :key => true, :nullable => false
property :role_id, Integer, :key => true, :nullable => false

2. Deprecated:
  2.1 Integer with explicit :serial option is deprecated, use Serial instead
property :id, Integer, :key => true, :serial => true, :field => 'unitsindex'
property :id, Serial
  2.2 +options[:class_name]+ is deprecated, use :model instead
belongs_to :customer_address, :class_name => "CustomerAddress", :child_key => [:customer_address_id, Integer]
  2.3 explicit use of 'in' operator is deprecated
belongs_to :order, :model => 'Order', :child_key => [:order_id, Integer], :order_type.in => ['O', 's', 'w'], you can use
:order_type => ['O', 'S'] instead.

3. Others
  model.new_record? now model.new?
  model.update_attributes now model.update

DM hook before :save

I've been using DM's hooks a lot to do the customized validation. Today I was trying to set a property before save,

It won't work.

Finally, I figured it out, use attribute_set

Constanize the merb controller

I am implementing an authorization system now. There are two sub-system:
  1. Role based control system
  2. Rule based authorization system

The role sub-system is relatively easy to implement. I am going to talk about the rule based authorization system only here.

According to the requirement, the authorization system is very detail orientated. What does that mean? I can give you a very simple example here:
   For role 1, he can view e1, but can view, edit, delete e2
   For role 2, he can view, edit, but not delete e1, can view e3
   For role 3, he can view, edit and delete, archive e1, no any permissions on e2 and e3

In our system, we have 50+ entities, and maybe 20 roles. You can imagine how many possibilities you can have here. Thank god, I've designed the system mostly in the RESTful way. So the next problem is how can I get all the controllers and callable actions. There are two situations I have to address first:
  1. My controllers has name space
      Purchasing::PurchaseOrder
  2. My controllers not inherited from the Application directly, they might have their own hierarchy.

It turns out pretty simple in Merb and Ruby way.(This is another reason I like it over Java's reflection). The key is to Dynamically instaniating a class by name. Here is the code.

DataMapper - some tiny issues within 0.9.9

I am working on a home-grown authorization system. It is very customized for our special requirement. I have to hack DataMapper to get the job done. The more I dig in DM, the more I love it. I can't imagine how much code I have to write to do the same thing if I do it with Java. As a relative new ORM framework, it sure has some corners that might not work well for you, following are some thing I found out in one day:

1. auto_migrate! vs. auto_upgrade!


I also noticed that there is a plugin dm-constraints, I haven't check it out yet, but it seems like the same, here is the code from the plugin:


I filed an issue report on lighthouseapp.com.

UPDATE(Feb-21-2009): Just got the note from Dan Kubb( one of the core DM developers):
"The Collection#destroy! method is actually supposed to bypass all hooks. The way you're doing it by looping over the records and calling each Resource#destroy method is the proper approach to execute each Resources' hooks.
In dm-core 0.10.0 there will be a Collection#destroy method that wraps this up and essentially does the same thing."

This makes a lot of sense. Like always, I really appreciate the attitude of the developers from DM, that is one one the reason I am using DM.

dm 0.9.8 breaks YAML.dump

If you are wondering why your code stop working on dm 0.9.8, this could be one of the reason:
The DM 0.9.8 breaks the after you do any operation on the result Array:


So the workaround could be:
1. Issue only one query to get all you need
or
2. If you can not do 1, then you have to get all the ids, then use (:id.in => ids) to make it working.

Hope this could save you sometime to figure out the very strange error info.

Here is the ticket on light house.