On Fri, Jan 16, 2015 at 7:32 AM, Emmanuel Bernard <emmanuel(a)hibernate.org>
wrote:
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.
The new contracts are very specific. So I do not think this is a problem.
However, I would not necessarily agree with needing to cover *all* of "the
various NamingStrategy implementations we have in the code base".
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?
This is true. But remember that this is mainly intended to signify a
secondary table, whose name cannot be implicit. Also, I think that mixing
implicit naming and explicit naming and expecting that to work is not
necessarily a valid expectation.
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).
I can see this working by allowing naming strategy to accept "rules"
(insert better name here) that define componentized aspects of the naming
rule. For example, consider:
new AggregatedNamingStrategy(
AllLowerNamingRule.INSTANCE,
DotToUnderscoreRule.INSTANCE,
DollarSignToUnderscoreRule.INSTANCE
);
Though, I think some of these fit better in implicit naming and others in
physical naming.
+1 to enforce that a table name must be unique for a given entity
across
all catalogs/schemas.
Emmanuel