HQL's special use of the "id" property name interferes with user Object models ------------------------------------------------------------------------------ Key: HHH-1127 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1127 Project: Hibernate Core Issue Type: Improvement Components: core Environment: Hibernate HQL in all of its versions up to the recent version 3.1 Reporter: Gunther Schadow Original Estimate: 8h Remaining Estimate: 8h When a user decides to use the name "id" as the name of a property, HQL queries break with unspecific exceptions, because HQL assumes "id" as reserved for the Hibernate id attribute defined in the hbm file using the <id .../> tag. This is bad design in our view, because it puts an unnecessary constraint and interference with the otherwise transparent "object persistence for idiomatic Java." For example, a mapping file may contain: <class name="MyObject"> <id name="internalId" ... /> <property name="id" .../> <property name="foo" .../> </class> now I like to make an HQL query from MyObject where id='123' and this would fail because 'id' in HQL means the 'internalId' property not the property called 'id'. I could hack org.hibernate.persister.entity.EntityPersister, changing line public static final String ENTITY_ID = "id"; to public static final String ENTITY_ID = "hid"; But that of course is breaking it for anyone who uses "hid" as a normal property name. I think the flaw here is that HQL should use the hbm metadata to take the attribute designated as by the class/id/@name attribute in the mapping file rather than using this static constant "id" literal. The following classes use the ENTITY_ID constant: hql/ast/tree/DotNode.java hql/ast/tree/FromElement.java hql/ast/tree/FromElementType.java hql/classic/PathExpressionParser.java persister/entity/AbstractEntityPersister.java persister/entity/AbstractPropertyMapping.java persister/entity/EntityPersister.java and most of the work would be in PathExpressionParser, for someone who knows this it should not take more than a day to fix. The problem is that it would break backward compatibility with existing HQL queries. But there is really no alternative than to make the change, because either you keep it a perpetual problem for new users or you make it a short term problem for old users. One might consider using some special symbol, such as "@id" to stand as an alias for the actual name of the id property. That would make conversion really easy.