first of all kudos to raSantiago and folks for stepping up and doing some due diligence, work and prototyping. I think it helps to keep the team thinking about potential new technologies that we can adopt in the future.

I think the debate about ORM vs SQL has been in existence since the days of ORM. I also think DB_DO has some fairly primitive ORM capabilities (which we have not exploited as much). So moving to a better full fledged ORM is definitely an option.

Both Matt and Rob make some good points that should be noted and addressed. The ORM layer is one part of the puzzle, i'm a lot more interested in seeing how all the pieces fit and play together. So am looking forward to the blog posts and code to come.

Would be great to continue with the dedupe example to basically rebuild the dedupe system in civicrm and show some of the pros/cons of the new system, couple of thoughts:

Step 1: Merge two contacts (already implemented)
Step 2: User interface to merge two contacts (with user options to select which parts to merge and skip)
Step 3: API for the above merge process
Step 4: Dedupe rules and applying these rules to find merge candidates etc (this gets into both complex queries and relatively complex UI). i.e. the same functinality that CiviCRM 2.2 exposes today. Step 5: An API for the above

lobo