On Fri, Jan 16, 2015 at 7:32 AM, Emmanuel Bernard <emman...@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
>
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
