On 13 Oct 2004, at 19:44, Luca Garulli wrote:
Ok, what I'm trying to say is that using JDO you don't worry so much about persistence theme, optimization, support of N database, etc.
My understanding is that you are only paying attention at what you want to say, and not to our arguments which eventually led to choosing a different persistency mechanism. I don't mean to offend you with that - I just want to say that, because of persistency modelling and performance issues, we have chosen _not_ to use an O/R tool, also because many of them are more focussed around "business-type objects".
Why would no-one try to implement a Subversion clone using EJBs? Or why does many large-scale systems come up with their own O/R layer (think Amazon, eBay, etc).... because their development and deployment context, and the nature of the data which they manage, can't be handled automagically by a generic business object/rdbms mapping tool. Sometimes the benefit during development time having not to worry about persistency will be thrown back in your face when you go live and encounter performance/stability issues. We prefer to tackle one supported database at the time, and just make sure we don't _depend_ on any specific one.
Also, we wanted the number of dependencies to be as small as possible. Example: I've been running the new Jira release for a while now, and I'm still continuously amazed with the huge amount of (unreleased, time-stamped, pre-alpha) jar files they want in their classpath. No doubt this will be the same with Confluence. Sticking to JDBC made us depend on a single jar for each database. Do the simplest thing which might possibly work.
(which eventually forced me to say much more than I wanted to say about the topic - I'd rather prefer people to look at the functionalities first) :-)
HTH,
</Steven> -- Steven Noels http://outerthought.org/ Outerthought - Open Source Java & XML An Orixo Member Read my weblog at http://blogs.cocoondev.org/stevenn/ stevenn at outerthought.org stevenn at apache.org
