[eclipselink-users] SecondaryTable mapping question

[Laird Nelson <ljnelson@xxxxxxxxx>]

I have a legacy mapping question.

I have a table called id_rec (this is from a 30 year old database).  It
stores, basically, a row for just about every single thing in the system.

I have another table called profile_rec.  It stores, roughly, person-related
data, and has a foreign key back to the id_rec table.

All things being equal, I'd like to map these to a single object.  Let's
call it Person.  I'd like to annotate this like this (partially, and from
memory, so forgive syntax errors):

@Entity
@Table(name = "id_rec")
@SecondaryTable(name = "profile_rec", pkJoinColumns =
@PrimaryKeyJoinColumn(name = "id"))
public class Person {
  //...
}

Now, I'm assuming that if I do this, and I persist() a Person, I will get a
new row in the id_rec table and the profile_rec table.

"But wait," some of you are thinking--and exactly, I foresee a wrinkle
here.  What if--this is hypothetical for this example, but realistic for
other similar ones--what if a row already exists in the id_rec table with,
say, a pk of 5, and I insert a new Person whose primary key ("id") is set to
5?  Is EclipseLink smart enough to realize that it should do an "upsert" on the
id_rec table?  Or will it try, blindly, to slam two INSERTS home, thus
causing the transaction to roll back?

Expanding this example out a bit, I'm looking for a convenient way to map
what are effectively roles within this ancient database into a simple Java
API.  I realize that I could of course make a Person have a @OneToOne
relationship with an ID/Party/Thing, but I really don't want to have the
Thing (id_rec) be something that is composed inside another object.  That
is, I want any given role (account holder, student, train engineer,
whatever) to simply include his "base" information from the (related) id_rec
record.  This looks exactly like what @SecondaryTable is intended for,
PROVIDED that when you're "attaching" a new role record to an *existing* base
information record the provider is smart enough to do an UPDATE on the id_rec table, not an INSERT.

I hope I've been articulate enough to explain my problem.

Thanks,
Laird