On Thu, Oct 22, 2009 at 10:33 AM, Laird Nelson <[email protected]> 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
