Article:
  Flawed Understanding of JDO Leads to FUD
Subject:   JDO makes DB dependent on Java
Date:   2002-05-30 17:43:50
From:   tomdavies
Response to: JDO makes DB dependent on Java

No, JDO allows you to specify the mapping between the DB schema and your object model. It is more work, and I certainly enjoy the freedom of being able to introduce new persistence capable classes and needing to write only a trivial mapping descriptor (e.g. <class name="Letter" persistence-capable-superclass="ItemImpl"/>)


I think there will be cases when it is appropriate to do a fully specified mapping of your objects to your schema -- for instance, if you ever decide to change JDO vendors you would either need to export and import your data, or set up the same mapping for both JDO implementations.


What properties of the default mapping which your JDO implementation uses do you see as making the schema inappropriate for use from other languages?


I don't think that lack of control over schema mapping in JDO is a valid reason for using entity beans, although this will depend on your vendor. I've only used Solarmetric's Kodo, which does allow you to control this mapping.


Tom

Full Threads Oldest First

Showing messages 1 through 2 of 2.

  • JDO makes DB dependent on Java
    2002-05-31 11:17:46  dblock [View]

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