cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven Noels <stev...@outerthought.org>
Subject Re: Daisy as CMS: why don't use JDO?
Date Thu, 14 Oct 2004 09:13:25 GMT
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


Mime
View raw message