2

Is there a tool to generate JDO objects from an existing database? I prefer a awesome looking Eclipse plugin which i could use to generate and maintain the object but it seems that this is currently not existing. Are other, simple tools to generate the database objects?

Roel Veldhuizen
  • 4,613
  • 8
  • 44
  • 78

1 Answers1

1

JDO objects are not simple wrappers around database rows (although you can implement your JDO objects as simple wrappers around database rows if that is what you wish). As such, most automated tools will not know how the object is to be presented by only looking at the database.

For example, an object like:

public class Person {

   private List<PhoneNumber> phoneNumbers;

   ...

   public List<PhoneNumber> getPhoneNumbers() {
     ...
   }

}

might have JDO pre-fetching all the phone numbers for direct inclusion into the object. In the relational database this would probably be done by joining the PhoneNumber database table with the Person database table when constructing the Person object.

Other implementations might look like

public class PhoneNumber {

   public Person getPerson() {
     ...
   }
}

And force the user to fetch a person's phone numbers in a separate database request. It's just not possible for a general purpose tool to predict which manner you wish to use. With two choices (as presented here) it's pretty easy to say "make it configurable!" However, after you add eight or more independent choices in combination, it is not clear that it would be easier to configure the class generation (as opposed to writing the class outright).

Not to mention that JDO wasn't designed for class generation in mind, in fact it was designed to make your hand written classes persistent without generation because the class generation technologies of the day left a lot of visible cruft (undesirable naming patterns, exposed conflicting interfaces and methods, etc).

Edwin Buck
  • 69,361
  • 7
  • 100
  • 138
  • When the table Person has a N relation with PhoneNumber a tool should be able to notice this right? – Roel Veldhuizen Sep 15 '11 at 09:16
  • 1
    @Roel Veldhuizen, Yes, the theoretical tool would be able to notice the 1..N relationship in the database; however, it would not be able to correctly guess at how the records would best be accessed by the program. For example, a call history on a contact number might be better off included when pulling up the contact number, or it might be better off being pulled up independently of the contact number, or it might be better off to pull the history lazily as the history is explored. Knowing the right way the program needs the info isn't possible to deduce from the SQL tables alone. – Edwin Buck Sep 15 '11 at 14:09