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

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

Having enough defaults so that a pure stnadard .jdo file will handle the
most obvious cases is a huge step forward in usability, ease of use, and
reducing learning curve.

I think htis should be a major objective actually. Not only does it make it
easier to work with, but I have found that easeo of use ascpects like this
tend to force cleaner architectures as well.

> 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


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