Hi Wonseok,
Sorry for not replying sooner. I was out of the office for the last
few days.
First, a brief explanation:
There are some historical reasons in TopLink why both
foreignKeyFieldName and the ForeignKeyConstraint object exist. The
ForeignKeyConstraintObject is the newer way of doing things, but due to
backwards compatibility requirements we have chosen to keep both ways of
doing things. In the past, some of the tooling that shipped with
TopLink relied on the foreignKeyFieldName. I am in the process of
determining if that is still the case and I will let you know the result.
I think the ideal approach to this problem is as follows:
1. deprecate setForeignKeyFieldName and getForeignKeyFieldName on
FieldDefinition and update DefaultTableGenerator to make use of
ForeignKeyConstraint instead.
2. Make the changes you suggest below to allow both types of foreign
keys to be used TableDefinition.buildForeignFieldTypes().
3. Update the entity-persistence-tests to use the non-deprecated API. I
realize this is a bit tedious, but I think we need to make that change
in order to completely fix the issue.
I assume there are more changes required to fix issue 1072.
As for the use of Generics in the schema generation code, the simple
answer is that you may now use generics in that code. For those that
have been working on the TopLink Essentials code for some time, a bit of
further explanation is required. Until fairly recently, we only allowed
Java 5-specific code in a few of our packages due to a requirement to
support core TopLink functionality on JDK 1.4. That requirement no
longer exists and as a result, Java 5 code can now appear in our core
packages.
-Tom
Wonseok Kim wrote:
> TopLink Team, please shed light on this so I can go ahead.
> I added some comments in the below,
>
> On 10/26/06, *Wonseok Kim* < guruwons_at_gmail.com
> <mailto:guruwons_at_gmail.com>> wrote:
>
> Hi Tom,
>
> I'm trying to fix issue 1072 - ddl generation of composite foreign
> key constraints.
> I think the ForeignKeyConstraints class is the right one to use if
> composite foreign key, but there is another foreign key setting in
> FieldDefinition.
>
> public class FieldDefinition implements Serializable, Cloneable {
> ...
> protected String foreignKeyFieldName;//fully-qualified foreign
> key field name
>
> But current code shows that if above foreignKeyFieldName is set,
> it ignores the TableDefinition.foreignKeys
> (ForeignKeyConstraints). See below.
>
> TableDefinition:
> private void buildForeignFieldTypes(final AbstractSession
> session) {
> Hashtable fieldTypes = session.getPlatform().getClassTypes();
> FieldDefinition field = null;
>
> Vector foreignKeysClone =
> (Vector)getForeignKeys().clone();
> setForeignKeys(new Vector());
> for (Enumeration enumtr = getFields().elements();
> enumtr.hasMoreElements();) {
> field = (FieldDefinition)enumtr.nextElement();
> if (field.getForeignKeyFieldName () != null) {
>
> addForeignKeyConstraint(buildForeignKeyConstraint(field, this,
> session.getPlatform()));
>
> }
> if (field.getType() == null) {
> field.setType ((Class)fieldTypes.get(
> field.getTypeName()));
> if (field.getType() != null) {
> field.setTypeName(null);
> }
> }
> }
>
> /* bug #2997188 constraints not getting generated when
> creating/replacing tables via TableCreator
> had to add the next few lines instead of removing the
> above code for backwards compatibility */
> if (getForeignKeys().isEmpty()) {
> //if foreignKeys is empty then we know we are not in 2.5
> setForeignKeys(foreignKeysClone);
> }
> }
>
> I'm curious, should we use either foreignKeyFieldName or
> foreignKeys (ForeignKeyConstraints)? We could not mix both of
> them? Is there any reason for not allowing this?
> entity-persistence-tests table creators are using only
> foreignKeyFieldName now, but If I would like to add composite
> foreign key constraints, how can I mix them?
>
>
> If there is no problem, I would like to support for both
> ForeignKeyConstraint object and foreignKeyFieldName by removing
> setForeignKeys(new Vector()) line and below lines.
>
> /* bug #2997188 constraints not getting generated when
> creating/replacing tables via TableCreator
> had to add the next few lines instead of removing the above
> code for backwards compatibility */
> if (getForeignKeys().isEmpty()) {
> //if foreignKeys is empty then we know we are not in 2.5
> setForeignKeys(foreignKeysClone);
> }
>
> Then we can use both FieldDefinition.foreignKeyFieldName (for simple
> foreign key) and addForeignKeyConstraint (for composite foreign key).
> What do you think?
>
> Also, I don't know there is any policy about code, but could I use
> Java SE 5 Generics in schema generation codes? This makes us avoid
> type-mismatch mistakes and easy to read code.
>
> Regards,
> - Wonseok
>
>