2:01 p.m.
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
3:57 a.m.
On 6 July 2016 at 21:01, Steve Ebersole <steve(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
8:43 a.m.
On Thu, Jul 7, 2016 at 3:58 AM andrea boriero <andrea(a)hibernate.org> wrote:
On 6 July 2016 at 21:01, Steve Ebersole <steve(a)hibernate.org>
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.
8:57 a.m.
On 7 July 2016 at 15:43, Steve Ebersole <steve(a)hibernate.org> wrote:
On Thu, Jul 7, 2016 at 3:58 AM andrea boriero
<andrea(a)hibernate.org>
wrote:
> On 6 July 2016 at 21:01, Steve Ebersole <steve(a)hibernate.org> 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.
9:23 a.m.
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.
3091
days inactive
3092
days old
4 comments
2 participants
participants (2)
-
andrea boriero -
Steve Ebersole