what happens if the object you are going to persist turns out to be a proxy class. Then I would end up putting a Proxy$440 (or whatever the generated class name is) instead of the appropriate value for the real class that would be generated in the getConcreteClass() call that is forwarded to the real thing.
thoughts? -----Original Message----- From: Thomas Mahler [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 04, 2002 1:08 PM To: OJB Users List Subject: Re: AW: mapping inheritance tree in one table Hi again, David Rault wrote: > Hi thomas > > i understand perfectly the situation (i'm a toplink user, so i know the > problem) > what puzzles me though is the need to have an attribute (which is what > is told in the 3rd tutorial) in the objects > to keep a data that is inherently _in_ the object > > my idea, which is submitted a PersistentField implementation for is to say > > when reading from database, we use the current instantiation mechanism > (which i trust is working :) ) > but when writing to the db, we surely do not need an attribute to > contain the class name do we ? Ah! Now I get your point. You want to avoid the extra attribute in the persistent class! cool idea. > > we just need a field to store the information : let's keep the special > field name "ojbConcreteClass", that's fine with me > and we need to tell OJB to call getClass().getName() on the to-be-stored > object to know what to write > > to be more precise : here's my (very classic) test classes : > > class ACCOUNT { > int id; > double value; > string number > } > > class SAVING_ACCOUNT extends ACCOUNT { > double rate; > } > > class BORROWING_ACCOUNT extends ACCOUNT { > double rate; > int duration > } > > i ve got a single table : > create table ACCOUNTS ( > id integer primary key, > concreteClass varchar, > value number, > numero varchar, > rate number, > duration integer, > } > > i simply do not want (i believe i don't _need_ it either) to add the > "String ojbConcreteClass" attribute in ACCOUNT class > > here's my repository.xml: > <class-descriptor class="ACCOUNT" table="ACCOUNTS"> > <extent-class class-ref="SAVINGS_ACCOUNT" /> > <extent-class class-ref="BORROWING_ACCOUNT" /> > <field-descriptor id="1" name="id" column="ID" jdbc-type="INTEGER" > primarykey="true" autoincrement="true" /> > <field-descriptor id="2" name="ojbConcreteClass" > column="CONCRETECLASS" jdbc-type="VARCHAR" /> > <field-descriptor id="3" name="number" column="NUMBER" > jdbc-type="VARCHAR" /> > <field-descriptor id="4" name="value" column="VALUE" > jdbc-type="DOUBLE" /> > </class-descriptor> > > <class-descriptor class="SAVINGS_ACCOUNT" table="ACCOUNTS"> > <field-descriptor id="5" name="rate" column="RATE" > jdbc-type="DOUBLE" /> > </class-descriptor> > > <class-descriptor class="BORROWING_ACCOUNT" table="ACCOUNTS"> > <field-descriptor id="5" name="rate" column="RATE" > jdbc-type="DOUBLE" /> > <field-descriptor id="6" name="duration" column="DURATION" > jdbc-type="INTEGER" /> > </class-descriptor> > > > so reading from the database is easy : i've got the ojbConcreteClass > field descriptor with its value > the setting of the attribute is useless, i don't need/want to > save it, my implementation just do nothing > and when writing, my PersistentField implemenation says that for the > ojbConcreteClass field descriptor the value is the result of > getClass().getName() > > is it clearer ? totally clear. I never had this idea! > and then is it wrong ? (i obviously might have missed something) > David No, it seems to be a very interesting solution. If you prepare a patch I'll check this in. A short howto notice is also very useful. thanks, Thomas -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
