[hibernate-dev] Naming and "naming strategies"

[Sanne Grinovero]

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.

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'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.

Sanne

On 13 January 2015 at 18:43, Steve Ebersole <steve at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev