On Fri, 2002-09-27 at 11:37, Gavin King wrote: > Damn! thats a tough one. I'm almost tempted to say that the best solution > would be to implement the new cirrus.hibernate.persister.ClassPersister > interface (in v1.1.1). This would be a decent solution if you just have a > couple of tables like this and you don't need to use outerjoin fetching or > the query language for those tables. (Well, actually you *could* probably > get nice and familiar with Hibernate's internals and wire in outerjoin > fetching and queries, I suppose.)
I have a *ton* of tables like this (500+). But I already have a fairly sophisticated relationship and query framework setup in my code generator and was planning to continue using it, so the fact that I can't use the query language isn't a big deal. (Not having to do things a particular way is a huge benefit of Hibernate over other persistence schemes, IMO.) Would implementing ClassPersister be the way to go for this? At first (and uninformed) glance it would seems like all I'd need to do is override insert() from EntityPersister and instead of setting the ID to the IDENTITY value returned, set a particular field in the ID to the IDENTITY value returned. > Hold on.....somethings not right.....the IDENTITY column has to be unique of > its own accord, right? Yes, but for various reasons the IDENTITY field is not the only field in the key. The joys of retrofitting :-) Chris -- Chris Winters ([EMAIL PROTECTED]) Java Developer ------------------------------------------------------- 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
