As former ObjectSpaces (RIP) PM, I attended several object-persistence presentations today. Gavin did a really good presentation - his passion came across clearly. Many of the things he presented were good words of wisdom. But here are a few things that I see differently:
1. Adding view-like capabilities in mapping: (a la Hibernate 3 filter): This gives me a pause. Most relational DBs have excellent view definition capabilities that far exceed what little "mapping languages" can provide. Plus the views get their due scrutiny for updatability, correctness and efficiency. Do we really need three different places where data filtering happens - DB, mapping file and source code (Java/C#/...)?Now I know that many programmers complain that their DBAs don't let them add views. But is this feature the right solution for an organizational problem? (Disclaimer: I used to be part of the SQL Server org until a few months ago so my thinking may be a bit biased here :-) )
2. Data integrity/quality constraint enforcement at various levels: All layers except the database (e.g. UI, mid-tier app or common mapping) have a rather limited view of data. They may see only a subset of data or incompletely processed data (triggers, stored procedure logic, other apps, nightly runs etc.). The feature may be useful in some cases, but it is very prone to abuse. The real question here is - should we be guiding our users to do more and more with object models to a point that they don't take care of long lived data? More about this in the next bullet.
3. App-driven database design: If an app lasts a decade, the data used by the app often lasts five decades or more. For most valuable data, data quality issues far exceed the quality issues that a consuming/producing app is concerned about.