Re: AW: [Objectbridge-jdo-dev] jdo extension
Brought to you by:
thma
From: Thomas M. <tho...@ho...> - 2002-05-24 17:34:31
|
Hi Travis, tr...@th... wrote: > 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". ;-) > But it would be 100% JDO compliant ;-) > So maybe we still need the repository.xml just for the database > info? Mhh. WOuld be possible. But I I think this would be even more confusing for the user than using a repository.xml exclusively! > 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? > I fear its the default setting for the SourceForge mailinglists. A lot of people have complaint about it, but SF tells you that they want you to press "reply all" !!! cheers, Thomas > ---- 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 > > > > > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > _______________________________________________ > Objectbridge-jdo-dev mailing list > Obj...@li... > https://lists.sourceforge.net/lists/listinfo/objectbridge-jdo-dev > > > > > > 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 > > > > > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > _______________________________________________ > Objectbridge-jdo-dev mailing list > Obj...@li... > https://lists.sourceforge.net/lists/listinfo/objectbridge-jdo-dev > > > > >> >>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 > > > > > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference August > 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > _______________________________________________ Objectbridge-jdo-dev > mailing list Obj...@li... https://lists.sourceforge.net/lists/listinfo/objectbridge-jdo-dev > > > > > |