I have to say I disagree with Ingo’s comments about preferring “bare bones Sql” over O/R mapping technology. IMO, the two topics are orthogonal.
Data Access is all about solving high level use cases. There are no rules out there that say one must give up the explicit, low level control just because an O/R mapping technology is utilized. In fact, I would suggest that a good O/R mapping technology needs to be easy to use AND extensible. That is it should solve all the common problems easily, but at the same time allow low level control as required. Generation of sql statements is just one possible service an O/R mapping technology can provide. Due to the wide range of transactional requirements and relational schemas currently existing, I believe that even a world class O/R mapping technology can only support 90% of the real world, Sql generation scenarios.
In regard to the scenario Ingo suggests. ObjectSpaces will provide the ability for the user to provide their own custom sql statement (including stored procedures) to both select data from the database and to persist changes. ObjectSpaces also gives the user full control over the Sql connections, thereby allowing explicit control of the transaction semantics. Sure, a majority of ObjectSpaces users will not need this sort of control, but it will be there for the ones who do. I really don’t see any reason why ObjectSpaces couldn’t solve the Ingo’s scenario.