[hibernate-dev] "matching" table/column names (and naming strategies)

andrea boriero andrea at hibernate.org
Thu Jul 7 04:57:49 EDT 2016


On 6 July 2016 at 21:01, Steve Ebersole <steve at hibernate.org> wrote:

> 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 also prefer the mapping not to change based on the chosen naming strategy

>
> 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.
>
> In my opinion make sense not supporting implicit naming strategy.

What about comparing the names after having previously removed, if
presents, the quoting chars?

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
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>


More information about the hibernate-dev mailing list