Bug 154972 - Metadata API: JDBC... Classes need sane implementation of hashCode/equals
Metadata API: JDBC... Classes need sane implementation of hashCode/equals
Status: NEW
Product: db
Classification: Unclassified
Component: DB schema
6.x
All All
: P4 (vote)
: 7.0
Assigned To: Libor Fischmeistr
issues@db
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-12-08 22:19 UTC by Rob Englander
Modified: 2013-08-01 12:53 UTC (History)
0 users

See Also:
Issue Type: DEFECT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Rob Englander 2008-12-08 22:19:28 UTC
The generation of the internalName using an incremented counter in JDBCForeignKey means that two equivalent instances
will have different hash codes.
Comment 1 David Vancouvering 2008-12-09 00:43:44 UTC
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.
Comment 2 Jiri Rechtacek 2009-02-10 15:13:15 UTC
Reassigned to new owner.
Comment 3 matthias42 2012-03-17 22:00:56 UTC
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.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo