cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luca Garulli <l.garu...@gmail.com>
Subject Re: Daisy as CMS: why don't use JDO?
Date Thu, 14 Oct 2004 09:46:22 GMT
On Thu, 14 Oct 2004 11:13:25 +0200, Steven Noels
<stevenn@outerthought.org> wrote:
> 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.

Ok, I understand your point of view. You think that a GENERIC tool for
OR mapping cannot resolve large scale and complex systems... Sorry but
I don't agree. There are several success stories about JDO (you can
find some of these on www.JDOCentral.com) and other OR technologies
(Hibernate? OJB?).

I agree with you for EJB use (never used in large industrial
projects!), but JDO is all another thing.

Take a look to jpox (http://www.jpox.org). It's open source and has
several features of JDO 2 (coming...).

> 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.

It's as to say: "I don't want to use any MVC framework since I don't
want performance/stability problems!!! I'll start to write my own..."

When you'll need more features from you repository such as advanced
caching, multiple DBMSs support and others, maybe you'll think: "why I
had to implement all these things by hand? And if I use a good product
for it?"

> 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.

Why do you use OpenJMS? Maybe it was better to rewrite a new custom
message system to avoid performance/stability...

> (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) :-)

bye,
Luca Garulli
OrienTechnologies.com
(the light ODBMS, all in one JDO solution)

Mime
View raw message