Article:
  Flawed Understanding of JDO Leads to FUD
Subject:   JDO makes DB dependent on Java
Date:   2002-05-31 11:17:46
From:   dblock
Response to: JDO makes DB dependent on Java

Tom Davies said:
No, JDO allows you to specify the mapping between the DB schema and your object model. It is more work,
<snip>


That work would be necessary for our applications, and for any application that is starting from a fixed schema. If there is a performance or extensibility benefit to JDO over an Entity Bean solution, JDO may still be a better choice, but in our situation, I think that the work required is going to be about the same- you're going to have to do the R to O mapping somewhere.


Further, Tom Davies asked:
What properties of the default mapping which your JDO implementation uses do you see as making the schema inappropriate for use from other languages?
<snip>


I don't know - I am using Entity Beans right now :)


However, I don't see the database people letting their expertise be replaced by an algorithm written somewhere else.


Thanks for your informative response - I'll watch this carefully and 'embrace change' if it's appropriate.


-Dave

Full Threads Newest First

Showing messages 1 through 1 of 1.

  • JDO makes DB dependent on Java
    2002-06-02 00:33:30  tomdavies [View]

    If there is a performance or extensibility benefit to JDO over an Entity Bean solution, JDO may still be a better choice, but in our situation, I think that the work required is going to be about the same- you're going to have to do the R to O mapping somewhere.

    I think that the benefits of JDO over EB are in the transparency of the persistence, rather than a difference in the amount of work required to state the mapping. For instance, JDO allows persistent classes to be part of an inheritance hierarchy, so that a query can return a heterogeneous collection of concrete subclasses of an abstract class, as long as the query condition can be expressed in terms of persistent fields of the abstract base class. I believe that EJB2.0 can't do this.

    As far as performnace goes, I think performance depends on the implementation for both JDO and EB. In any case a lot of performance depends on having sensibly sized transactions and choosing the right isolation level whatever access technology you use.

    However, I don't see the database people letting their expertise be replaced by an algorithm written somewhere else.

    I'm sure you're right -- I'm lucky, I don't have any 'database people' :-). I think you could make a case for using the default JDO generated schema during development and then designing and mapping the final schema as parts of your object model stabilise -- there's no reason why you can't have a partially automatically generated and partially manually mapped schema.

    Tom