openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Laird Nelson <>
Subject Deducing a primary key, customizing in ReverseCustomizer?
Date Thu, 22 Oct 2009 14:33:35 GMT
Before I spend a lot of time going down the wrong path, I thought I'd ask
the (rather silent these days?) users list what the best approach is.

I work for a company that has a 30 year old database that chose for all
sorts of reasons to have many of its tables defined without primary keys.
Of any kind.

What such tables *do* have are unique indices.

For the sake of this argument, assume that for various valid and invalid
reasons we cannot go back and add true primary keys.  I am actually working
on seeing if this is possible--it's quite obviously the most appropriate
solution.  But, failing that, a human being can glance at the DDL for these
tables, and, being familiar with some naming conventions, can determine
which of potentially many unique indices is the "real" one that is treated
by the rest of the application as that table's primary key.

My challenge is to see if I can perform the same analysis from within the
bowels of an OpenJPA ReverseCustomizer and so cause the ReverseMappingTool
to spit out JPA entities with @Id annotations, even in the case where the
tool, unassisted, could not discover any primary key information.

My initial thought was to perform this analysis within the
customize(FieldMapping) method.  Then I saw the Javadoc for FieldMapping and
realized it had somewhere around 100 methods (by inheritance).  Egad.

Before I begin the long, slow process of understanding these hundreds of
methods, does anyone know if at customize(FieldMapping)-time I have access

* The names of unique indices found so far (I presume yes)
* The ability to "step in" and inform the ReverseMappingTool that the field
mapping under consideration is to be output as a primary key, even though
that information was not present in the database

...?  If I don't have these abilities, then this is the wrong path to go

Thank you,

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message