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

[Andy L. <aj...@as...>]

missed the list...sorry....

> THe spec allows jdo files a several levels - system, package, etc.
>
> As far as the connection info, I would limit the info contained in the
> jdo file to a symbolic reference to the conenction, and allow the
> connection to be specified elsewhere  - respository.xml or some other
> item that can be loaded from the class path, or even programmatically.
> Keep in mind that some people are going to want to package all the JDO
> stuff in a
> JAR/WAR/EAR, and it may not be convienent to modify resource entires
> within that archive at deployment time.
>
>> 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
>> >
>>
>> >
>> >
>> >
>> >
>>
>>
>>
>> _______________________________________________________________
>>
>> 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
>
>
> "The heights of genius are only measurable by the depths of stupidity."


"The heights of genius are only measurable by the depths of stupidity."