> Differently from JPA, it also allows one to use OODBMSs, Excel, Google
> BigTable, Amazon EC2 and so on in addition to relational databases.
>
> By selecting JPA you cut of the possibility to use e.g., db4o as persistence
> engine.
I agree that JDO is a great technology. But I don't think it is useful
to switch between RDBMSs, OODBs, GraphDBs, BigTable or other
persistence strategies. If you try to abstract them away, you loose a
lot of their power.
Take the easy to use, type safe native queries of most OODBMs for an
example. Using them through JDO would force you to use JDOQL...
Also, for each of the named persistence solutions you need to know how
they work to write performant code. Take BigTable for example, without
thinking about a good schema and keys, you end up with very bad
performance. Its not possible to just throw your objects into such a
store. Looking at JPA projects, entites are often modeled with
database in mind - tis may be good or bad, but its often neccessary to
get good performance.
Of cource, JPA does not solve any of these problems - it just solves
your relational needs. But it does it well, and my argument is that
you would end up to rewrite your repositories if you try to switch
from an RDBMs to BigTable for example.
> (IMO there are far too many systems out there that routinely use a RDBMS as
> persistence engine. In many cases an OODBMS would have done the job with
> significantly less development effort.)
I agree, but I am not sure if we need all this abstraction. One of the
main advantage of an OODB is easier development - why should we
complicate things with JDO, and end up with more complexity than we
have with JPA? ;-)
Piero
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
