[hibernate-dev] "matching" table/column names (and naming strategies)
This is something that has been bothering me for a long time. HHH-6328[1]
is a specific example. Basically we are very inconsistent in how we
attempt to match up table and column names, especially when there are
naming strategies involved. We see this with secondary tables,
@org.hibernate.annotations.Table, etc.
Consider the following mapping:
@Entity
@Table( name="`USER`" )
class User {
...
}
The question is how they should refer to this table in other annotations
such as @Column or @org.hibernate.annotations.Table e.g.
And part of this gets to whether the implicit or physical naming strategies
should have any part in the matching process. I think I am not a fan of
the mapping having to change just because they plug in a new naming
strategy. So ideally I'd prefer that the naming strategies not take part
in this process.
I guess I just wanted to start a discussion about how to best deal with
this.
One option is that they need to match exactly (maybe with some simple
handling of quoted versus case-insensitive, similar to Identifier#equals
leveraging Identifier#getCanonicalName), e.g.:
@Entity
@Table( name="`USER`" )
@org.hibernate.annotations.Table( appliesTo="`USER`", ... )
class User {
...
}
I guess the first question here is whether we want to support referring to
implicit table names in other annotations at all. JPA for the most part
discourages this; in order for a table name to be referenced in other
annotations it should be named explicitly.
Another option is to leverage the "logical name" (implicit or explicit) and
to apply a Identifier#equals-like check for matching. This would however
lead to what I mentioned above wrt naming strategies playing a part in the
matching. Consider we base matching on the logical name and that we have:
@Entity
@org.hibernate.annotations.Table( appliesTo="user", ... )
class User {
...
}
So this *might work* depending on the configured naming strategies. But it
is also therefore highly dependent upon the naming strategies and changing
the naming strategy could conceivably cause the match to no longer find the
table.
A sort of hybrid approach between those 2 would be to use a specific
"matchable name determination strategy" (think JPA implicit naming rules).
At the very least, as HHH-6328 shows again, we really ought to stay away
from simple String comparisons. Even a simple move to using Identifier for
the comparisons would help in that specific area.
[1] https://hibernate.atlassian.net/browse/HHH-6328