Index and unique-key constraints not properly handled with implicit columns in hbm.xml binding

Description

Indexes defined in XML mapping files are not considered for Metadata and SchemaExport in the following cases:

  • Defined in a property, e.g. <property name="name" index="person_name_index" type="string"/>

  • Defined in a many-to-one, e.g. <many-to-one name="personGroup" foreign-key="person_persongroup_fk" index="person_persongroup_index" class="PersonGroup"/>

In Version 4.3 the index creation worked fine.

Environment

Hibernate 5.0.2

Activity

Show:
Steve Ebersole
October 26, 2015, 4:50 PM

The problem here is that the initial processing of the XML is only creating an IndexConstraintSource if the column is specified (either via attribute or element). In the 2 failing cases, the column is implicit, and we skip creating the IndexConstraintSource. That is a bug.

Steve Ebersole
October 26, 2015, 4:51 PM
Edited

I have not verified yet, but I'd assume is the same underlying cause. They are both handled by the same code.

Steve Ebersole
October 26, 2015, 6:20 PM

I pushed the tests upstream showing the problem here. See org.hibernate.test.hbm.IndexTest. I marked the failing tests with @FailureExpected.

the work around for now would be to explicitly name the column. The problem in the current code is that at the time we are trying to create the IndexConstraintSource we have not yet resolved the implicit column name. And we cannot. The solution will be to delay the handling of indexex (and unique keys) at all until later for hbm.xml binding.

Steve Ebersole
October 28, 2015, 1:26 AM

This is going to require changing the design of how indexes and unique-keys are modeled at that source-level. We went with that approach initially in hopes of catering to both hbm.xml and annotation binding with a single model. However that never came to fruition, and likely never will as we plan to deprecate hbm.xml bindings later as part of the jandex-binding work.

All that said, doing that change will take more than a day which means it will miss 5.0.3 which is scheduled for tomorrow. So I scheduled for 5.0.4

Assignee

Steve Ebersole

Reporter

F. Martin

Fix versions

Labels

None

backPortable

None

Suitable for new contributors

None

Requires Release Note

None

Pull Request

None

backportDecision

None

Components

Affects versions

Priority

Major
Configure