Deducing a primary key, customizing in ReverseCustomizer?

[Laird Nelson <lj...@gmail.com>]

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

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

Thank you,
Laird

Re: Deducing a primary key, customizing in ReverseCustomizer?

[Laird Nelson <lj...@gmail.com>]

On Thu, Oct 22, 2009 at 10:33 AM, Laird Nelson <lj...@gmail.com> wrote:

> Before I begin the long, slow process of understanding these hundreds of
> methods, does anyone know if at customize(FieldMapping)-time I have access
> to:
> * 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
> down.
>

OK, got it working.

For those who care:

The ReverseMappingTool does not actually let your ReverseCustomizer decide a
table's table type if it detects that the table does not have a primary
key.  So even if your customizer is written to tell the system, hey, this
table is a base table, and even if it's written to install a PrimaryKey onto
that table, that method will never be called.

Instead, in the setTool() method, I got all the tables, iterated through
them one at a time, installed my inferred PrimaryKeys (marking each as
logical), and then returned--sure enough, my customizer is now called by the
tool as though these tables actually did in fact have primary key
information.

Thanks,
Laird