On Jul 25, 2011, at 12:41 PM, Sebastian Schaffert wrote: > Dear Bertrand and Stefane, > > to get the thread back on-topic, some in-line replies ;-) > > Am 25.07.2011 um 11:38 schrieb Bertrand Delacretaz: > >> On Mon, Jul 25, 2011 at 11:20 AM, Stefane Fermigier <[email protected]> wrote: >>> On Jul 25, 2011, at 10:44 AM, Bertrand Delacretaz wrote: >>>> ...ORM is an anti pattern anyway ;-) >> >>> ...since Sebastian and his team made a great deal of effort to create their >>> own ORM ("Object-RDF mapping") >>> in the first place, we'd better acknowledge instead that "object-something >>> mappings" are useful tools, >>> with (as all tools) some limitations that one needs to be aware of... >> >> To me the main problem with SQL-to-object mappers is, as explained in >> the seldo.com blog post, that if SQL is the wrong model for your data >> (i.e. your data is not relational), mapping that to objects won't >> help. I just creates more mess ;-) >> >> I haven't looked closely at what Sebastian's team have implemented in >> this case, but an object to RDF mapping might make perfect sense if >> RDF is the right model for your project and the mapped objects help >> you access it. No impedance mismatch in that case. > > > What we are really doing is an RDF-to-relational database mapping, and ORM is > mainly the vehicle to create an abstraction from the different database > vendors. It would not be so difficult to get rid of the ORM completely, > because we are essentially just working with relational data.
OK, then you probably need some database abstraction layer, and not an ORM. I don't know what's available in the Java world. In Python, we have SQLAlchemy which has both a database abstraction layer and an ORM, and you can use the former without the latter. This is viewed as a huge benefit of SQLAlchemy over other Python ORMs (at the expense of a slightly steeper learning curve). There was an interesting discussion on this subject last week on Reddit: http://www.reddit.com/r/Python/comments/iupwe/sqlalchemy_and_you/ OTOH, in the Java world, JPA is the standard (a good standard, I think, overall, and one with several implementations which is healthy). In the Python world there is no standard for ORM, so solutions are judged more on their technical merit that on adherence to a given standard. OK, in the Java world there is another standard, JDO (http://en.wikipedia.org/wiki/Java_Data_Objects). I have never used it so I can't comment. > Performance- and complexity-wise it would definately make sense. But we would > loose database independence, an argument that was often brought before, > because companies typically already have a certain database landscape, they > have DBAs that are expert on one system, they have fast servers running > already one system, backups in place, ... Indeed. We at Nuxeo love Postgres, but also support, because that's what our customers ask for: MS SQL Server, Oracle and MySQL (+ H2 for tests). We will probably also support DB2 in the future. For Stanbol to be used alongside Nuxeo in real-life projects, it's important (not a blocking issue, but not just a nice-to-have either) that Stanbol supports the same databases, or can be easily tuned to support new ones when needed. S. -- Stefane Fermigier, Founder and Chairman, Nuxeo Open Source, Java EE based, Enterprise Content Management (ECM) http://www.nuxeo.com/ - +33 1 40 33 79 87 - http://twitter.com/sfermigier Join the Nuxeo Group on LinkedIn: http://linkedin.com/groups?gid=43314 New Nuxeo release: http://nuxeo.com/dm54 "There's no such thing as can't. You always have a choice."
