[hibernate-dev] Naming and "naming strategies"

[Steve Ebersole]

On Fri, Jan 16, 2015 at 7:32 AM, Emmanuel Bernard <emmanuel at 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
>
>