[hibernate-dev] Naming and "naming strategies"

[Steve Ebersole]

See inline...

On Tue, Jan 13, 2015 at 3:30 PM, Sanne Grinovero <sanne at hibernate.org>
wrote:

> Funny I just praised the "NamingStrategy" in the OGM thread. So I
> agree people badly want to specify their own "physical" naming
> strategy but I don't see any value into making the logical
> representation pluggable.
> It's probably important to make sure all code uses the same thing
> anyway for consistency; so I'd make it public so that extending
> frameworks / advanced tooling can comply to the same rules but not
> public as in a replaceable component.
>
> If we agree on that, the user will probably not be aware of us using a
> logical strategy which is different. So I'd hope we could keep the
> "NamingStrategy" name to mean the physical one? Because that's how
> what a lot of people call it today.
>

Well the *concept* of being able to hook in to the either the implicit and
physical naming processes is certainly awesome.  By "a mess", I just mean
specifically how it is currently done.

And, see, I *think* you are proving my point about how confusing this all
is.  There are actually 3 different types of strategies represented in the
current NamingStrategy:
* implicit naming
* logical naming
* physical naming

I agree that *most* people care about hooking into the physical naming
process.  However, I think that some users also care about implicit
naming.  But this is why I think it makes the most sense to split these out.

I disagree that reusing the name NamingStrategy for "physical naming
strategy" is the right thing to do.  For a few reasons.  First, its
confusing imo to long-time users (same name, completely different methods).
Also, I'd be confused if I was presented with a NamingStrategy, but then an
ImplicitNamingStrategy (and possibly a LogicalNamingStrategy); "what's the
difference?"



> Great idea to use typesafety like the Indentifier. But could you make
> it an interface instead? The presence of the boolean will otherwise
> double the size of the object in memory (24 bytes instead of 12), so
> I'd hope that we could actually use two different implementations. I'm
> assuming we'll have many such Identifier instances around. N.B. even
> in the case of just 12 bytes, it's 12 bytes on top of those of the
> pure-string representation.. but probably worth it in terms of better
> code.
>
> public interface Identifier {
>    String getText();
>    boolean isQuoted();
>    QuotedIdentifier quote(); //optional: we could add this if you
> think it's going to be a common operation as we'd be able to reuse the
> instances.
>    UnquotedIdentifier unquote(); //as above
> }
>
> public interface QuotedIdentifier extends Identifier {
>

I really dislike this idea of split quoted/unquoted identifier contract.
It just feels like leaking an awful lot of impl details just for some
premature optimization.


> ...
>
> I'm a bit lost about the LogicalNaming proposal. Why do these need to
> be strings at all?
> I think I'd organize them into some form of immutable matrix and then
> use them primarily based on references. The elements of the matrix
> would possibly be able to have nice debug-friendly toString
> implementations and possibly render the physical names as well so that
> users - aware only of the physical representation - aren't completely
> clueless when reading errors in logs.
> But I probably missed the purpose.
>

First, I am really not sure what you mean by "some form of immutable
matrix".  As for why the representation as Strings... well, one of the
state goals for 5.0 was to continue to use org.hibernate.mapping package to
represent the result of processing the mappings and to minimize any changes
to that model.  Objects in org.hibernate.mapping represents these as
Strings, ergo...

Their "purpose" mainly is essentially in maintaining a set of
cross-references.  Going back to the original example: @Column(...,
table="some_table") obviously we need some form of cross-referencing to be
able to resolve the *string* "some_table" to a org.hibernate.mapping.Table
reference.