This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
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 same. 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.