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
