Perhaps an even better solution to this, that would not require "custom" PersistentField implementation, and would solve some other problems, would be to allow defining a field descriptor WITH NO FIELD - then you could provide a conversion class that fills in the proper value on write, and ignores the value on read. This makes it easier to write custom storage of class id - there would be a default ClassIdentifierFieldConversion that works as currently required, less the actual field, but you could write a custom ClassIdentifierIdFieldConversion that maps classes to some integer value that maps in your database.
Another enhancement/way to do this would be to be able to set a field-descriptor with an absolute value rather than an attribute name. This could solve other problems as well, such as relationships between tables that have some external identifier. > -----Original Message----- > From: Thomas Mahler [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, December 04, 2002 2: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]>
