Mailing-List: contact users-help@openjpa.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@openjpa.apache.org
Received-SPF: pass (nike.apache.org: domain of ljnelson@gmail.com designates
 209.85.219.219 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:date:message-id:subject:from:to:content-type;
        b=lvdv8KvRUfKNpNQMrj5HjqmUuf++CTOmRq2XAzuqiUVW0b424/R0HHuetGfluDe32U
         LGhwB7OCtVGXDBlbUoKxLsINbDKKx7p29+hRqUD3eGBVzeWlEVvMu9qiwutP9MnSEnuC
         SdS2pPLmuuDAVhEN+0EFzIDGnlHhKF7vl/0f8=
MIME-Version: 1.0
Date: Thu, 22 Oct 2009 10:33:35 -0400
Message-ID: <2c0ebf0c0910220733n5cb6be0ck8af84e4f9f2aa04c@mail.gmail.com>
Subject: Deducing a primary key, customizing in ReverseCustomizer?
From: Laird Nelson <ljnelson@gmail.com>
To: users@openjpa.apache.org
Content-Type: multipart/alternative; boundary=0016e6d64514ffa143047686fa06

--0016e6d64514ffa143047686fa06
Content-Type: text/plain; charset=ISO-8859-1

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

--0016e6d64514ffa143047686fa06--