On Thu, 14 Oct 2004 11:13:25 +0200, Steven Noels <[EMAIL PROTECTED]> 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)
