[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2235?page=all ] Christian Bauer resolved HHH-2235: ---------------------------------- Resolution: Rejected The map index is part of the primary key of the collection table. No column in a primary key can be null. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2235?page=c... ] Emmanuel Bernard commented on HHH-2235: --------------------------------------- (parent_id, name) is the primary key. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2235?page=c... ] Emmanuel Bernard commented on HHH-2235: --------------------------------------- Not on all databases. Conceptually null should not be part of a primary key and some database enforce that rule. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2235?page=c... ] Ulf gohde commented on HHH-2235: -------------------------------- sorry was in a hurry... lots of typos in the previous comment. Let's do it again: I don't agree with this statement. You don't have to have a primary key at all, instead you can use a UNIQUE CONSTRAINT and all databases support null values in a UNIQUE CONSTRAINT. Imagine a table like DOC_TYPE, STATE, WATERMARK; unique constraint(DOC_TYPE, STATE) to specify watermarks to be imprinted in certain documents. For some document types you want to be able to configure the watermarks based on some possible states of the document, for other types you just want one watermark independent of the state. In that situation it makes perfect sense to have null in your unique constraint. Otherwise you have to come up with a weird "reserved" state and all your code has to be aware of that "special" value. When I define the key in hibernate based on this unique constraint, I am getting a null object back when querying with "where doctype='xyz' and state is null". Is this by design at the moment meaning it would be a change request or is it a bug? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2235?page=c... ] Christian Bauer commented on HHH-2235: -------------------------------------- And if you really believe that a relation "doesn't need a primary key at all" you are in for more surprises. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2235?page=c... ] Christian Bauer commented on HHH-2235: -------------------------------------- You want to learn what the term "relation" means in the relational data model. Hint: it has nothing to do with "relationship". You also need to understand that "null value" means "I don't know something because it is not there". No part of a primary key can be unknown. Every table needs a primary key. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2235?page=c... ] Ulf gohde commented on HHH-2235: -------------------------------- And the term relational database is derived from the capability of relating tables to each other via a relationship. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2235?page=c... ] Ulf gohde commented on HHH-2235: -------------------------------- Especially this note is interesting. "(Note that in SQL the heading is not always a set of column definitions as described above, because it is possible for a column to have no name and also for two or more columns to have the same name. Also, the body is not always a set of rows because in SQL it is possible for the same row to appear more than once in the same body.)" which makes it clear that a primary key is optional. But that is not the point because usually you have to be able to uniquelly identify a row. That is also true in my example hence the unique constraint. The point is you can uniquely identify a row even if one of the columns in the unique constraint is null. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2235?page=c... ] Christian Bauer commented on HHH-2235: -------------------------------------- Dude, a primary key is not optional. A relation is a set of tuples. Oracle and some other SQL databases allow bags of tuples (by not requiring a primary key), which breaks many of the features of the relational data model, most importantly, avoiding duplicate data. You can not identify a single tuple if there are duplicate tuples in a bag. SQL and the stuff that Oracle provides has NOTHING to do with the relational data model. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2235?page=c... ] Christian Bauer commented on HHH-2235: -------------------------------------- Sure, most SQL DBMSs have broken NULL handling. When you INSERT a row, you might avoid duplicates in Oracle because they treat NULL as some special value (they have other crazy ideas about NULL, too). But NULL is not a value, you not compare two NULLs and get a true/false answer, hence, you can not determine uniqueness. So other DBMSs allow nullable columns in composite unique constraints but just ignore NULLs during INSERT check (MySQL I think). In DBMSs it only works as long as there is only a single row with a NULL value (SQL Server)! You will get duplicate rows and that is exactly the reason why the SQL guys came up with the notion of "primary key", which means a unique key that has no nullable components. (That is, a "candidate key" as defined by the relational data model. There are no NULLs in the relational data model.) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira