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?

Main Topics Oldest First

Showing messages 1 through 1 of 1.

  • 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