I'm still having a bit of a problem envisioning a persistence framework handling "complex sql queries". Two simple discussions backup up my doubts:
"SubQueries in JDOQL, Equivalent of SQL SubQueries"
"JDO vs Redundance..., performance issue encountered in pratice"
I think the query mechanism is the key issue when designing OPF.
I think that the query mechanism is the last thing to consider ;)
There are much more important questions about the design of an OPF, which should be first discussed, like how transparent the OPF should be, how it should deal with the business objects etc.
Moreover, if we try to eat the whole elephant, we won't manage ;) We should start with a simple and cut down version, without query support, etc.
The problem with a cut down version is that it's pretty easy to achieve. I'm looking for a little more than simple table-to-object mapping. Simply not having to handcode Sql INSERT/DELETE/UPDATE statements is not enough ;-)
Major problem in most persistence frameworks is lack of proper query support.Most people see the power of Sql queries (and the runtime efficiency), and they miss the same power using objectqueries. Take OPATH of OS, does/will it support things like SUM(), COUNT(), etc? If not, why not?
Of course you're able to loop over objects and SUM yourself, but is that efficient? Experience proves it's not performing.
Resume: let's start working on an initial prototype for basic persistence, but don't forget the critical issue.
Another place to take a look:
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.