Article:
  Flawed Understanding of JDO Leads to FUD
Subject:   JDO makes DB dependent on Java
Date:   2002-05-30 08:57:32
From:   dblock
From what I understand, and I'm no JDO expert, using JDO means you design your data model in Java and then export it to the database. After you run your code, you go look at the database to see what JDO did.


We're designing our database schema much more carefully than that, since it will be the foundation for many apps in several different languages, with fundamentally different requirements. Is this a situation where JDO is definitely not appropriate? It seems so.


JDO seems to work when the persistence framework is an afterthought, and all the data manipulation is going to happen within your Java data model.


When there is legacy data, legacy schema, other applications that access the same data, it seems that something more flexible is required.


BTW, we're using perl to load our DB, and Entity beans to do the O/R mapping (so far - we can be convinced otherwise).


Any comments?

Full Threads Oldest First

Showing messages 1 through 3 of 3.

  • JDO makes DB dependent on Java
    2002-05-30 17:43:50  tomdavies [View]

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