Yes, now that makes sense... I'm going to have to think this through a little more, because my current code doesn't take that into consideration.
You were right when you said this is a "little involved"... :-) ----- Original Message ----- From: "Gavin King" <[EMAIL PROTECTED]> To: "Jon Lipsky" <[EMAIL PROTECTED]> Cc: "hibernate list" <[EMAIL PROTECTED]> Sent: Tuesday, October 15, 2002 4:13 AM Subject: Re: [Hibernate] Looking for Volunteers > > Currently in the MultiTableEntityPersister there fields such as > > "subclassTableNameClosure" that get initialized with the information about > > the persistant objects subclasses. Currently, when I get the persister > for > > the object "Multi" above, I get information about Simple, Multi, and > > SubMulti. The inclusion of SubMulti in the information is currently what > is > > causing my trouble in generating the SQL statements since I am not using > > outer joins between the tables containing Simple and Multi (and SubMulti, > > since it get's included right now.) > > Yes, SubMulti should be included. Because when we load an object by id or by > a query we don't know if it might be an instance of a subclass at the time > the SQL query is issued. So what happens is that often Hibernate uses a > different persister to *initialize* the object to the one it uses to query > the database. So each MultiTableEntityPersister has the "tableNames" field > to hold all tables used to persist the state of the concrete class, and the > "subclassTableNameClosure" field to hold all tables used to persist the > state of that class and, potentially, its subclasses. > > Make sense? > > ----- Original Message ----- > From: "Jon Lipsky" <[EMAIL PROTECTED]> > To: "Gavin King" <[EMAIL PROTECTED]> > Cc: "hibernate list" <[EMAIL PROTECTED]> > Sent: Tuesday, October 15, 2002 12:22 AM > Subject: Re: [Hibernate] Looking for Volunteers > > > > Hey Gavin, > > > > I'm still working on getting the query functionality working with the > > MultipleTableEntityPersister and I have a question that you may be able to > > answer before I go spend hours and hours tracing the functionality. > > > > In order to understand my question, I've attached the mapping xml that I > am > > currently testing with: (which is a modified version of the one currently > > checked into CVS.) > > > > <hibernate-mapping> > > > > <class name="cirrus.hibernate.test.Simple" table="rootclass"> > > <id type="long" column="id_" > > > <generator class="assigned"/> > > </id> > > <version name="count"/> > > <property name="name"/> > > <property name="address"/> > > <property name="date" column="date_"/> > > > > <joined-subclass name="cirrus.hibernate.test.LessSimple" > table="subclass"> > > <superclass-key column="id_"/> > > <property name="intprop"/> > > <one-to-one name="other" class="cirrus.hibernate.test.LessSimple"/> > > <property name="foo" column="other"/> > > </joined-subclass> > > > > <joined-subclass name="cirrus.hibernate.test.Multi" > table="nuthasubclass"> > > <superclass-key column="sid"/> > > <property name="extraProp"/> > > <property name="multiDate" column="date_"/> > > > > <many-to-one name="other" class="cirrus.hibernate.test.Multi"/> > > <many-to-one name="parent" class="cirrus.hibernate.test.Multi"/> > > > > <set role="children" > > > <key column="parent"/> > > <one-to-many class="cirrus.hibernate.test.Multi"/> > > </set> > > > > <joined-subclass name="cirrus.hibernate.test.SubMulti" > table="submulti"> > > <superclass-key column="sid"/> > > <property name="amount"/> > > </joined-subclass> > > > > </joined-subclass> > > > > </class> > > > > </hibernate-mapping> > > > > Now for the question: > > > > Currently in the MultiTableEntityPersister there fields such as > > "subclassTableNameClosure" that get initialized with the information about > > the persistant objects subclasses. Currently, when I get the persister > for > > the object "Multi" above, I get information about Simple, Multi, and > > SubMulti. The inclusion of SubMulti in the information is currently what > is > > causing my trouble in generating the SQL statements since I am not using > > outer joins between the tables containing Simple and Multi (and SubMulti, > > since it get's included right now.) > > > > My question is, did you intend to load the information about SubMulti in > to > > the arrays? Before I go and change something, I wanted to see what your > > original intention of that was. > > > > Thanks, > > Jon... > > > > > > ----- Original Message ----- > > From: "Gavin King" <[EMAIL PROTECTED]> > > To: "Jon Lipsky" <[EMAIL PROTECTED]> > > Cc: "hibernate list" <[EMAIL PROTECTED]> > > Sent: Saturday, October 12, 2002 4:53 AM > > Subject: Re: [Hibernate] Looking for Volunteers > > > > > > > Ace! Thanks Jon ... looking forward :) > > > > > > ----- Original Message ----- > > > From: "Jon Lipsky" <[EMAIL PROTECTED]> > > > To: "Gavin King" <[EMAIL PROTECTED]> > > > Cc: <[EMAIL PROTECTED]> > > > Sent: Saturday, October 12, 2002 2:04 AM > > > Subject: Re: [Hibernate] Looking for Volunteers > > > > > > > > > > Hi Gavin, > > > > > > > > I spent a few hours today working on this, and I think I have it about > > > > finished. > > > > > > > > - It can now handle two columns with the same name in different > tables. > > > > - It now will work for both Oracle and Ansi style joins > > > > - It works for insert, update, and load by primary key. > > > > > > > > All I have left to do is finish the "select" code, and then I'll > submit > > it > > > > for you to play around with. Right now, the code for generating the > > > selects > > > > is about finished, all I have left to do is to figure out how to get > the > > > > portion of the select statement needed to load the MultipleTableEntity > > in > > > > sync with the rest (Right now the alias names don't match up.) > > > > > > > > I'll won't be able to continue working on this until Monday, so don't > > > expect > > > > anything before then. > > > > > > > > Jon... > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Gavin King" <[EMAIL PROTECTED]> > > > > To: "Jon Lipsky" <[EMAIL PROTECTED]> > > > > Cc: <[EMAIL PROTECTED]> > > > > Sent: Friday, October 11, 2002 9:27 AM > > > > Subject: Re: [Hibernate] Looking for Volunteers > > > > > > > > > > > > > I'm pre-warning you that this will be a bit involved, Jon - and you > > will > > > > > probably have to change the Loadable interface, refactoring some > stuff > > > > thats > > > > > currently done in the Loader hierarchy onto the XXXXEntityPersister > > > > classes. > > > > > > > > > > I don't have an existing testcase, but if you add a many-to-one > > > > association > > > > > to some class in Multi.hbm.xml, that will be enough. > > > > > > > > > > MultiTableEntityPersister implements table-per-subclass persistence. > > > > > EntityPersister implements the old-style persistence. > > > > > > > > > > Currently MultiTableEntityPersister is a valid implementation of > > > > operations > > > > > from ClassPersister and Queryable but *not* of all operations > defined > > on > > > > > Loadable. ie. MultiTableEntityPersister defines the operations > needed > > by > > > > > SimpleEntityLoader but not by OuterJoinLoader. > > > > > > > > > > At the moment, I am generating SQL along the lines of: > > > > > > > > > > select > > > > > t.id as id1, t.clazz as clazz1, t.prop as prop1, > > > > > t1.subprop as subprop1 > > > > > from roottable t > > > > > left outer join subtable t1 > > > > > on t.id = t1.id > > > > > > > > > > for the _query_ stuff. That will have to change in a couple of ways: > > > > > > > > > > (1) it doesn't handle the case of two columns with the same name in > > > > > different tables > > > > > (2) it shouldnt always be an outerjoin really .... sometimes it > should > > > be > > > > > just a join > > > > > > > > > > but thats enough to get us started. Baby steps. So if you generate > > > > something > > > > > similar for outerjoin loading, we will be in business. > > > > > > > > > > P.S. I just noticed that because MultiTableEntityPersister doesn't > > > support > > > > > outerjoin loading, it also can't be loaded by CollectionLoader or > > > > > EntityLoader. So this is an important thing to finish. > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > From: "Jon Lipsky" <[EMAIL PROTECTED]> > > > > > To: "Gavin King" <[EMAIL PROTECTED]> > > > > > Sent: Friday, October 11, 2002 4:34 PM > > > > > Subject: Re: [Hibernate] Looking for Volunteers > > > > > > > > > > > > > > > > Hi Gavin, > > > > > > > > > > > > Not a problem. If you can point me to a valid test case for this, > > I'd > > > > be > > > > > > more than willing to make sure the outer join fetching works. > > > > > > > > > > > > Jon... > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Gavin King" <[EMAIL PROTECTED]> > > > > > > To: <[EMAIL PROTECTED]> > > > > > > Sent: Wednesday, October 09, 2002 6:56 PM > > > > > > Subject: [Hibernate] Looking for Volunteers > > > > > > > > > > > > > > > > > > > Okay, I finally have something concrete for normalized > > > > > > (table-per-subclass) > > > > > > > mappings. I went down a couple of wrong paths before I decided > on > > > the > > > > > best > > > > > > > approach (a completely new implementation of ClassPersister). > > > > > > > > > > > > > > I can save/load/update/delete instances already. > > > > > > > > > > > > > > We need (in order of importance): > > > > > > > > > > > > > > * SchemaExport support (and proper support in the mapping > > document) > > > > > > > * Query language integration (the hard bit) > > > > > > > * Support for outerjoin fetching > > > > > > > * Support for versioning (easy) > > > > > > > * support for native id-generation (not very hard) > > > > > > > > > > > > > > If anyone wants to help out with any of these problems, I would > > very > > > > > much > > > > > > > appreciate it. > > > > > > > > > > > > > > ( In particular, since Jon Lipsky understands the outerjoin > > fetching > > > > > code, > > > > > > > maybe he would have a look at that stuff? ) > > > > > > > > > > > > > > I'm perhaps being slightly over-eager here, since I still need > to > > > > rework > > > > > > the > > > > > > > map package part of this; what I've got there now is kludge. But > I > > > > will > > > > > do > > > > > > > that (and finish it) tomorrow. When I do that, it will knock the > > top > > > > > item > > > > > > > off the list by side-effect and make the other items doable. > > > > > > > > > > > > > > Anyway, if anyone can spare the time, please stick your hand up > > and > > > I > > > > > will > > > > > > > point in right direction.... > > > > > > > > > > > > > > Gavin > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > > > > This sf.net email is sponsored by:ThinkGeek > > > > > > > Welcome to geek heaven. > > > > > > > http://thinkgeek.com/sf > > > > > > > _______________________________________________ > > > > > > > hibernate-devel mailing list > > > > > > > [EMAIL PROTECTED] > > > > > > > https://lists.sourceforge.net/lists/listinfo/hibernate-devel > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > This sf.net email is sponsored by:ThinkGeek > > > > Welcome to geek heaven. > > > > http://thinkgeek.com/sf > > > > _______________________________________________ > > > > hibernate-devel mailing list > > > > [EMAIL PROTECTED] > > > > https://lists.sourceforge.net/lists/listinfo/hibernate-devel > > > > > > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by:ThinkGeek > > Welcome to geek heaven. > > http://thinkgeek.com/sf > > _______________________________________________ > > hibernate-devel mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/hibernate-devel > ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ hibernate-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hibernate-devel
