Re: [hibernate-dev] "matching" table/column names (and naming strategies)
On 6 July 2016 at 21:01, Steve Ebersole 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@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] "matching" table/column names (and naming strategies)
On Thu, Jul 7, 2016 at 3:58 AM andrea boriero wrote:
> On 6 July 2016 at 21:01, Steve Ebersole wrote:
>
>>
>> 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.
>
I was not so much asking about leveraging the ImplicitNamingStrategy. More
I was asking conceptually whether we want to allow this at all.
What about comparing the names after having previously removed, if
> presents, the quoting chars?
>
Personally, I think using straight String comparisons is the main problem.
If you look at the code for Identifier#equals that is really exactly what
we need already.
We cannot just drop the quotes for an accurate comparison. "`MY_TABLE`"
and "`my_table`" are different tables to each sane and SQL spec compliant
database. But conversely "MY_TABLE" and "my_table" are the same table.
Overall though I think it is reasonable to just expect to match an explicit
name. Especially if we allow org.hibernate.annotations.Table#appliesTo to
be empty like javax.persistence.Column#table, etc as a means to refer to
the root table.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] "matching" table/column names (and naming strategies)
On 7 July 2016 at 15:43, Steve Ebersole wrote:
> On Thu, Jul 7, 2016 at 3:58 AM andrea boriero
> wrote:
>
>> On 6 July 2016 at 21:01, Steve Ebersole wrote:
>>
>>>
>>> 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.
>>
>
> I was not so much asking about leveraging the ImplicitNamingStrategy.
> More I was asking conceptually whether we want to allow this at all.
>
+1 for requiring explicitly naming tables and columns in order to be
referred in annotations.
>
> What about comparing the names after having previously removed, if
>> presents, the quoting chars?
>>
>
> Personally, I think using straight String comparisons is the main
> problem. If you look at the code for Identifier#equals that is really
> exactly what we need already.
>
> We cannot just drop the quotes for an accurate comparison. "`MY_TABLE`"
> and "`my_table`" are different tables to each sane and SQL spec compliant
> database. But conversely "MY_TABLE" and "my_table" are the same table.
>
That's true, so if one or both names are quoted, we can remove the quoting
chars and do a case-sensitive comparison otherwise we we can do a
case-insensitive comparison, am I right?
>
> Overall though I think it is reasonable to just expect to match an
> explicit name. Especially if we
> allow org.hibernate.annotations.Table#appliesTo to be empty
> like javax.persistence.Column#table, etc as a means to refer to the root
> table.
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] "matching" table/column names (and naming strategies)
>
> Personally, I think using straight String comparisons is the main
>> problem. If you look at the code for Identifier#equals that is really
>> exactly what we need already.
>>
>> We cannot just drop the quotes for an accurate comparison. "`MY_TABLE`"
>> and "`my_table`" are different tables to each sane and SQL spec compliant
>> database. But conversely "MY_TABLE" and "my_table" are the same table.
>>
>
> That's true, so if one or both names are quoted, we can remove the quoting
> chars and do a case-sensitive comparison otherwise we we can do a
> case-insensitive comparison, am I right?
>
Correct. That is more or less what Identifier#equals does, although atm in
the interest of simplicity it simply leverages the
Identifier#getCanonicalName of the 2 Identifiers to perform the
comparison. Identifier#getCanonicalName lowercases the name if not quoted,
and then #equals compares that return.
We should really adjust this however as it can lead to false positive
hits. Consider comparing "`my_table`" and "my_table" which really ought to
evaluate to not-equal[1]. However the canonical name in both cases is the
same ("my_table") and so would evaluate to equal.
[1] I believe this is database dependent - whether a quoted and non-quoted
identifier can ever refer to the same database/schema object.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
