Re: Mapping Tutorial Take 1

[Thomas Mahler <th...@web.de>]

hi again,

Brian McCallister wrote:
>> 1. with the latest cvs head the jdbc-type attribute is now optional. 
>> If no type is specified, OJB tries to deduce a proper type from the 
>> Java type of the persistent field.
>>
> 
> Excellent, I had thought it should be able to do this. It will be in for 
> 1.0 I presume?

yes.

> 
>> 2. I'd prefer to see some more detail on the overall structure of the 
>> repository.xml and the include mechanism. (As I did it in the 
>> tutorial1.html). But maybe you approach is better as it liberates the 
>> user from too much knowledge about internal things?
>>
> 
> I agree completely that the repository.xml needs a thorough explanation 
> - I also think that the explanation should be orthogonal to using the 
> various API's however.

+1 (there are only very few API dependend things with the repository. 
Setting a isolation level only makes sense for ODMG, auto-update and 
auto-delete have different semantics for ODMG and PB)

>> 3. In the advanced topics section we should also mention mapping of 
>> inheritance hierarchies and polymorphism and link to tutorial3.
>>
> 
> Good call, will do.
> 
>>
>> The next question I have is where to place your tutorials. I think 
>> both tutorials together are a good replacement of my initial 
>> tutorial1.html.
>>
>> The only problem is that tutorial2 and 4 still rely on the 
>> presentation of the use cases from tutorial1. So this stuff must be 
>> moved to tutorial2, or tut2 and tut4 have to be rewritten too.
>> What do you think?
> 
> 
> Replacing tutorial2 is planned, 

cool!

> and replacing tutorial1 also requires 
> replacing tutorial4. Making use of JDO requires a lot more information 
> than tutorial4 actually gives, however. 

you're right. in it's current form tut4 is only a getting started text 
for the demo JDO demo application.

> I am not sure the best way to 
> tackle this, so am still thinking about it. 

Maybe we should not put too much energy in tut4 until the JDO solution 
has matured a bit.

> There is a lot of gray area 
> around the OJB+JDORI solution 

+1

(.jdo vs repository.xml not being the
> least an xslt to generate .jdo's from the repository.xml might not be a 
> bad idea down the line -- assuming OJB will pull metadata from either 
> source eventually).

To be 100% JDO compliant a JDO file is mandatory. So the most natural 
solution for a JDO implementation is to keep the metadata in JDO file(s).
At some point in time the OJB repository persistor will be able to read 
a repository.jdo file (enhanced with OJB vendor extensions) and to build 
up the OJB repository from this file.

Of course it can be helpful to have an xslt to generate repository.jdo 
files from repository.xml.

Thomas

> 
> -Brian
> 
>>
>> cheers,
>> Thomas
>>
>>> -Brian
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>>
>>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org