Hey,
First off thanks for working on this. This is quite a tedious topic and it’s easy to make
a mess out of it. Been there, done that ;P
The real test is to make sure we can implement:
- the existing default strategy
- the existing JPA strategy
- the various NamingStrategy implementations we have in the code base
If the split you are mentioning (Physical / Implicit) can be done while still implementing
the ones above, then big +1 from me. I like the idea of separating these two concepts. It
could become extremely handy for OGM if we decide that the implicit values needs to be
improved.
One thing that is itching me today is that OGM applies tiny tweaks to the implicit
mapping. If a user wants to change the physical part, he needs to basiclaly copy or extend
our strategy. This split would eliminate that problem.
I have one question, regarding logical name. The name that a given user needs to use
inside say @Column( …, table=“SomeEntity1”) is the name that comes out of the implicit
naming contract (assuming the original table was implicit). Is that correct?
Note to all, when you change the implicit naming strategy, (or the logical naming
strategy), then you *do* have an impact on the user mapping for artifact references. Say
my implicit naming strategy defines the table name as the entity name in reverse, the user
needs to use @Column(…, table=“1ytitnEemoS”). I don’t think I ever found a good solution
for that. The only solution I can think of is to have an default implicit naming strategy
for the mapping that is unrelated to the actual implicit naming strategy used to generate
the physical artifact names. And that gets very confusing.
Also, I’ve been toying with the idea of naming strategy AOP:
- ability to lowercase all columns
- ability to replace . with _
- ability to replace $ with something else
- etc
but I don’t see a good way to do this that would remain properly understandable by
everyone (incl. the same person 3 months later).
+1 to enforce that a table name must be unique for a given entity across all
catalogs/schemas.
Emmanuel
On 13 Jan 2015, at 19:43, Steve Ebersole <steve(a)hibernate.org>
wrote:
As I am working on 5.0, one of the things I am trying to accomplish is to
make the handling of table/column names more consistent and better
defined. The first step in that is to properly define the terms used often
throughout the codebase.
The first level of naming is the "given" name of a table/column. The given
name might be:
* explicit - explicitly specified by the user, as in @Table(
name="explicit_name" )
* implicit - not explicitly specified by the user and thus implicitly
determined (by JPA rules, "naming strategy", etc).
Next, we have a logical name which is a normalized form of the "given"
name. This is the form used to reference tables/columns internally. E.g.,
its how we resolve @Column(..., table="xyz"). More on this form later.
Finally we have the physical name of the thing, which is the actual name of
the table/column in the database. Again, this is generally a normalization
of the given name based on Dialect, "naming strategy", etc.
Today, we have a very messy concept called a NamingStrategy. I say it is
messy because it tries to combine unrelated concerns. So I still plan to
split this as I have outlined elsewhere into:
1) ImplicitNamingStrategy
2) PhysicalNamingStrategy
Which brings up my first question to y'all. Do we need a contract for
LogicalNamingStrategy? As I have said, the logical names are the things
used to resolve references. Allowing people to plug in custom strategies
for how that normalization works could be very dangerous. But even more
than that, is it really interesting to be able to hook into that process?
Historically, these names are all represented by String. So I also propose
to shift this to use that Identifier class we developed for the metamodel
redesign. For those that may be unfamiliar, it essentially combines the
String name with a "quoted" boolean:
public class Identifier {
private final String text;
private final boolean isQuoted;
...
}
Table names, then, are an aggregation of 3 Identifiers: one for catalog,
one for schema, one for table name. Same for named constraints
(ultimately, which is part of a improvement for 6.0 to allow indexes,
constraints, etc to be created in a separate schema from tables).
Since a major goal for 5.0 is to continue to use the org.hibernate.mapping
package as the representation of the mapping information, we obviously want
to minimize changes there to only what is completely essential. To that
end, if we are going to use Identifier over String stuff in the
org.hibernate.mapping package will need to deal with both; internally they
will hold the Identifier and use that to implement the String-based
name-related methods they expose.
Lastly I wanted to discuss the details of the logical names. For tables,
we currently qualify the table name with the catalog/schema info. There is
a mismatch in this regard when it comes to remaining a pure JPA
implementation. Consider @Column( ..., table="some_table"). Ultimately we
need to be able to qualify that with catalog/schema in order to be able to
construct a matching logical name (to be able to pair that with the
referenced org.hibernate.mapping.Table later). This is trivial when table
names are unique across all the catalogs/schemas (when there is only one
"some_table" in all the mapped catalogs/schemas). But is poses a problem
when the same table name is used from different schemas (e.g., when
"some_table" is mapped from both "schema1" and "schema2").
So we have a
choice. Since JPA does not say what is legal/illegal for the @Column.table
attribute, it is feasible for us to allow @Column.table to contain the
catalog/schema information in these cases as a selector. The only other
option I can see is to define a limitation that says that a table name must
be unique for a given entity across all catalogs/schemas. I don't think
that is generally a restrictive limitation. What are y'alls thoughts?
Perhaps this is one argument for allowing pluggable LogicalNamingStrategy?
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev