The generation of the internalName using an incremented counter in JDBCForeignKey means that two equivalent instances
will have different hash codes.
The problem here is that often a foreign key has no name; I guess I can give it an internal name based on the table and
column(s), rather than using a counter. That way if the key is the same from refresh to refresh we'll detect it as the
I'll look into this.
Reassigned to new owner.
The original reporter is right and wrong - if a sane implementation of hashCode was based on internalName, it would show the described error. But there is no implementation of HashCode or equals, so the object base implementations are invoked - with these the hashCode is _always_ different.
Still implementing the methods should be done and this should be considered.