RE: Re: AW: [Objectbridge-jdo-dev] jdo extension

[<tr...@th...>]

Problem...  

The jdo files are on a package by package basis, so you may have one jdo file per package, but what if you are using multiple packages, then having the database connection information is redundant and "bad".  ;-)

So maybe we still need the repository.xml just for the database info?  I am working on the other parts of it as we speak, but this part through me for a loop.

Travis

PS.  Thomas, can you change the reply to on these lists to go to the list?

---- Original Message ----
From: Thomas Mahler <tho...@ho...>
Sent: 2002-05-24
To: Sebastian Kanthak <seb...@mu...>
Subject: Re: AW: [Objectbridge-jdo-dev] jdo extension

Hi Sebastian,

Sebastian Kanthak wrote:

> Hi,
> 
> On Thursday 23 May 2002 10:49, Mahler Thomas wrote:
> 
>>If we need a *.jdo file to be JDO compliant we should generate it from the
>>OJB DescriptorRepository!
>>This is rather simple, fits to the existiting OJB metadata architecture and
>>it will allow to write 100% spec conformant *.jdo files (as they won't need
>>to contain vendor specifics)
>>
> 
> well, a spec conformant jdo-file may contain vendor-extensions, this is 
> covered by the spec. Of course, the semantics of these extensions isn't 
> specified.
> 

ACK


> A jdo file is required by the jdo-spec and it must contain all 
> persistent-capable classes at least. It can, however, contain as many 
> vendor-extensions as you want.
> 


ACK


> I think it would be a greate feature, if such a simple jdo file (without any 
> ojb extensions) would be sufficient to run ojb-jdo. 


Mhh. This would be great, but without extensions we won't be able to 
specify a foreign-key relation between two tables. We even won't be able 
to specify on what table a given class is mapped.

So this approach would work only for the most simple cases, where OJB 
can choose some common-sense defaults for table-names, etc.

> This would make it much 
> easier to change from any jdo-implementation to ojb and vice-versa. Table and 
> column names could be filled with default values, if nothing is specified. Of 
> course, one can override this in a way similar to what Travis proposed, if 
> one has to match an existing schema.
> 

> So my suggestion would be to generate all meta-data out of the jdo-file, 
> using default values where something isn't specified via an extension.
> 


This would be possible. The OJB RepositoryPersistor could be extended to 
build up the OJB DescriptoRepository from the JDO file. This should 
quite straightforward to implement.

In order to make this approach solid we will need vendor extensions to 
allow to have *all* meta-information required for OJB in the *.jdo file.
I suggest to use syntax element from the latest OJB repository DTD (see 
attached file). This new DTD defines the syntax for the OJB 1.0 
repository.xml. I hope there won't be too many changes on it till final 
relase.


> Of course, this has something to do with your point of view: Do you want to 
> use ojb and see jdo as a nice feature, or do you want to use jdo and see ojb 
> as one (of many other) implementations...
> 
> Perhaps, both approachs could be supported.
> 


I got your point! This is really a good argument to use a .jdo file 
covering *all* necessary information.

I now agree, that we should do it this way!

cheers,

Thomas