Hi Peter,

my first repository-user.xml does not contain the extent concept at all. I
simply did not set up a class-descriptor for BaseClass - just as you
described.

The extent concept came up to my mind when I thought that XDoclet would be a
great time saver to set up the repository. For each attribute in the model
class you declare an ojb.field, ojb.reference etc. Since the common
attributes are in BaseClass I wondered how to set them up via XDoclet for
each model class. That is why I guess U have to use the extent concept of
ojb.   

Any idea?

Dirk

-----Ursprüngliche Nachricht-----
Von: Peter Wieland [mailto:[EMAIL PROTECTED] 
Gesendet: Sonntag, 29. Februar 2004 16:47
An: [EMAIL PROTECTED]
Betreff: Re: Extent

Hi Dirk,

I'm not sure whether I understood your problem. Maybe I can help anyway...

First, I'm not sure whether you really need to declare the extents for all
your classes. Wouldn't it be sufficient to simply have all model classes
having the same superclass BaseClass. If this is the case, simply model
write a class-descriptor for each model class without any extent
declarations. The BaseClass doesn't even need an entry in the repository
file.

Of course, if you need to do queries using the BaseClass, this approach
won't work. You would then need to declare the BaseClass in the repository
with all it's extents. This would probably look like

<class-descriptor class="foo.bar.BaseClass">
  <extent-class class-ref="foo.bar.ModelClass1"/>
  <extent-class class-ref="foo.bar.ModelClass2"/>
  ...
  <extent-class class-ref="foo.bar.ModelClassN"/>
  <field-descriptor autoincrement="true" primarykey="true" column="id"
jdbc-type="VARCHAR" name="id"/>
  <field-descriptor column="version" jdbc-type="VARCHAR" name="version"/>
</class-descriptor>

In the latter case, I think you would have to redeclare the id and version
fields in each extent class together with the specific attributes for each
extent class:

<class-descriptor class="foo.bar.ModelClass1">
  <field-descriptor autoincrement="true" primarykey="true" column="id"
jdbc-type="VARCHAR" name="id"/>
  <field-descriptor column="version" jdbc-type="VARCHAR" name="version"/>
  <field-descriptor column="fieldAFromClass1" jdbc-type="VARCHAR"
name="fieldAFromClass1"/>
  <field-descriptor column="fieldBFromClass1" jdbc-type="VARCHAR"
name="fieldBFromClass1"/>
</class-descriptor>

I'm not quite sure, whether it is really necessary to redeclare the common
fields in each extent class, but I'm sure that it works this way as we are
using this approach. The column names for the extent classes do not need to
be the same for the same fields in different extent classes.

Using the extent-approach, you will have one separate table for each model
class, containing all the needed columns, included the "inherited" ones.

Hope that helps,

Peter


> Hi,

> I am using PB-API and DB2 7 for a few weeks now and have a question 
> regarding the ojb extent concept.

> I have a BaseClass which holds common attributes (timestamp, 
> versionnr) for model objects. Each model class has to extent 
> BaseClass. Database tables hold the common attributes and specific 
> attributes for the appropriate model class.

> In the repository-user.xml I declared the common attributes separately 
> for each model class-descriptor. My question is: Did I miss the 
> ojb-extent concept totally? Could I just declare a model class as an 
> extent-class of BaseClass and delete the common attributes from each 
> (model)class-descriptor because of the extent, ojb would handle these 
> attributes automatically for each extended class?

> thx,
> Dirk


> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to