Re: [Hibernate] generated field as part of composite key

[Chris W. <cwi...@op...>]

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 (cwi...@op...)
Java Developer