hibernate-devel

[Hibernate] generated field as part of composite key

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

I just recently discovered Hibernate and have been extremely pleased
with it so far. It will probably be replacing our Entity Beans scheme
shortly.

We're fitting Hibernate to an existing schema which is a little unusual:
every table in the system uses a composite key. I've created a composite
key object without a problem, but for some tables there's an additional
wrinkle as they use a generated field (e.g., IDENTITY in MS SQL) as part
of the composite key.

I don't expect Hibernate would have native support for something like
this, so how would I go about implementing it?

Thanks,

Chris

-- 
Chris Winters (cwi...@op...)
Java Developer

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

[Gavin K. <ga...@ap...>]

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.)

Hold on.....somethings not right.....the IDENTITY column has to be unique of
its own accord, right?

----- Original Message -----
From: "Chris Winters" <cwi...@op...>
To: <hib...@li...>
Sent: Saturday, September 28, 2002 1:38 AM
Subject: [Hibernate] generated field as part of composite key


> I just recently discovered Hibernate and have been extremely pleased
> with it so far. It will probably be replacing our Entity Beans scheme
> shortly.
>
> We're fitting Hibernate to an existing schema which is a little unusual:
> every table in the system uses a composite key. I've created a composite
> key object without a problem, but for some tables there's an additional
> wrinkle as they use a generated field (e.g., IDENTITY in MS SQL) as part
> of the composite key.
>
> I don't expect Hibernate would have native support for something like
> this, so how would I go about implementing it?
>
> Thanks,
>
> Chris
>
> --
> Chris Winters (cwi...@op...)
> Java Developer
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> hibernate-devel mailing list
> hib...@li...
> https://lists.sourceforge.net/lists/listinfo/hibernate-devel

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

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

[Gavin K. <ga...@ap...>]

> 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.

Well, almost. Might be a little bit of extra fiddling because there are two
versions of insert:

(1) take an id and return nothing
(2) take just the fields and return an id (meant for use with IDENTITY
columns)

You *have* to use version (2) because that version is called immediately
from save() rather than buffered for later.

To make sure (2) gets called you need to:

* override getIdentifierGenerator() to return an instance of NativeGenerator
(because its always Assigned for composite id classes)
* override isIdentifierAssignedByInsert() to return true
* Override insert() as you described. Return the id from this method.

Oh, a couple more things:

* EntityPersister is currently declared final and I will probably leave it
that way so use delegation, not inheritence
* I need to wire in a little bit of code to allow the mapping document to
specify a ClassPersister implementation class (I'll do that tomorrow)
* I changed the ClassPersister interface earlier today to generalize it a
bit. Grab a CVS update.

Gavin

>
> > 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 :-)

So MS SQL can generate

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

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

On Fri, 2002-09-27 at 12:33, Gavin King wrote:
> You *have* to use version (2) because that version is called immediately
> from save() rather than buffered for later.
> 
> To make sure (2) gets called you need to:
> ...

Cool. I'll see what I can do. Thanks for the clear pointers.

Chris

-- 
Chris Winters (cwi...@op...)
Java Developer

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

[Gavin K. <ga...@ap...>]

>
> > > Yes, but for various reasons the IDENTITY field is not the only field
in
> > > the key. The joys of retrofitting :-)
> >
> > So MS SQL can generate
>
> I just noticed that you had left this at the bottom of your last email.
> Did something get cut off or not completed?
>

Thats what happens when you write emails at 3 am. I meant to express my
interest in the fact that MS SQL can generate values that are unique, not
for the whole table, but only for other rows with the same values in the
other primary key fields. I never knew something like that existed...

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

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

On Fri, 2002-09-27 at 19:15, Gavin King wrote:
> Thats what happens when you write emails at 3 am. I meant to express my
> interest in the fact that MS SQL can generate values that are unique, not
> for the whole table, but only for other rows with the same values in the
> other primary key fields. I never knew something like that existed...

IDENTITY fields in MS SQL (and Sybase, for that matter) are very simple:
there can be only one IDENTITY field per table, and every INSERT is
guaranteed to generate a unique value for that field. Beyond that, you
can use them however you like -- they *can* (and frequently are) a
single primary key field, but that's not a requirement. 

Whether it's a good design to have an IDENTITY field as part of a
composite key is another discussion... :-)

Chris
 

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

[Gavin K. <ga...@ap...>]

> IDENTITY fields in MS SQL (and Sybase, for that matter) are very simple:
> there can be only one IDENTITY field per table, and every INSERT is
> guaranteed to generate a unique value for that field.

Yes, well you see that was my understanding also. My reading of that
statement is that the identity column *on its own* is a unique key of the
table (whether theres a UNIQUE constraint or not).

So a primary key constraint that includes an identity column is actually an
*error* in the relational model. The other columns are redundant.

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

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

On Sat, 2002-09-28 at 00:17, Gavin King wrote:
> Yes, well you see that was my understanding also. My reading of that
> statement is that the identity column *on its own* is a unique key of the
> table (whether theres a UNIQUE constraint or not).
> 
> So a primary key constraint that includes an identity column is actually an
> *error* in the relational model. The other columns are redundant.

Yes, they're redundant in the relational sense. But I don't think they
are in the performance sense which is one reason I believe they're used.
(I'm a little more curious about this now and will probably bug someone
about it on Monday.) But I'm not a database guy, just a developer :-)

Chris