Re: [hibernate-dev] [OGM] Store objects as actual typed objects via the native grid format

[Emmanuel Bernard]

What you are describing is what we want to do at some point but it is 
definitely a few steps further.
Usually, in the maturation cycle, we code things in the dialect and then we try 
to extract the logic out into core.

And since it’s a non trivial set of new features, I’d rather we go by 
reasonable steps:
1. dialect level POF/protobuf support
2. dialect level multi storage support
3. ability to express JPA mapping with a programmatic API (for multi mappings 
expression)
4. core level multi storage support
5. query level use of the multi storage support

Gunnar mentioned that at least for Hazelcast, you cannot necessarily pass the 
POF data directly to the grid, you might be in need of a 1-1 mapping between a 
POJO and a POF which is making the whole idea of step 1 more convoluted already 
if true.

Emmanuel

> On 13 Jan 2015, at 22:03, Sanne Grinovero  wrote:
> 
> Many interesting ideas.
> 
> Is the culprit not simply to be able to store the same entry into
> multiple (different) representations?
> I'd like to see the separation into "different representations" not
> being handled at the level of the dialect but higher up at level of
> OGM/ORM core, so that one could have - for example - some entities
> stored into a relational database, some other entities into MongoDB,
> and some entities into *both*.
> So configuration wise I'd have a section for each dialect, and then a
> way to tag each entity - possibly multiple times - to have then
> included into one of the configured databases.
> 
> You'd have two consequences:
> - you can have multiple instances of the same dialect type - for
> example two Coherence instances using a different POF encoding
> strategies
> - the Query engine can pick the best strategy among all storage
> options, across both differences of representation into the same
> database but also across query technologies / capabilities
> 
>@Entity @PersistenceGroup(“mongo-cluster-of-foos”, "cassandra-times")
>public Foo { … }
> 
> A limitation is that I'd probably want to be able to mark various
> additional mapping annotations as belonging to a specific database
> only. For example I think a relation annotation like @ManyToOne should
> be the same on all - as it's related to the structure of the Java
> domain model - but other annotations such as @Column would need to
> have a qualifier so I can pick multiple different ones. The obvious
> solution is that such mapping solutions need to be externalized into
> mapping files (exclusively).
> In practice this might not be a too strong limitation, in all places
> I've worked the "@Column" annotation was the quick and dirty solution
> but people would prefer to make a corporate standard NamingStrategy
> which would consolidate such decisions out of the model.
> 
> However you decide on those, the Query execution would need the smart
> planner we've fantasized about a bit.
> 
> Somehow related: remember Adrian Nistor from the Infinispan team
> developed a mapping tool based on annotations to map POJOs to
> Protobuf. This is ready for general usage now, and could be useful
> here.
> 
> -- Sanne
> 
> 
> 
> On 13 January 2015 at 17:24, Emmanuel Bernard  wrote:
>> 
>>> On 13 Jan 2015, at 18:06, Emmanuel Bernard  wrote:
>>> 
>>> Note that the user here (see question c), also asks for the ability to 
>>> denormalize the data and store a full object graph as one key and only a 
>>> subset as a second key which is something we want to do but that we don’t 
>>> have right now.
>> 
>> Actually, even that could be done by an ad-hoc dialect which would store the 
>> full entity graph in one schema / cache and the normal (according to OGM) 
>> entity in another schema/cache. The Dialect does not give you the entity 
>> graph but since we now know how to batch work, we could apply all changes on 
>> the virtual entry about to be persisted. This is essentially what we do in 
>> MongoDB’s dialect that we could replicate here.
>> 
>> Also, the POF(s) / Protobuf(s) for a given entity could be defined via the 
>> option system at the entity level
>> 
>>@Entity @UsingSchema(“someSchemaId”)
>>public Foo { … }
>> 
>> How to chose one vs the other at query time (via OGM) is what we are the 
>> farthest from I suspect.
>> 
>> Emmanuel
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev


___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] [OGM] Transaction type "RESOURCE_LOCAL", still JTA is required

[Emmanuel Bernard]

Probably. Needs exploring.

> On 13 Jan 2015, at 19:18, Gunnar Morling  wrote:
> 
> Hi,
> 
> For a demo I have an OGM application which defines a persistence unit with
> transaction type RESOURCE_LOCAL.
> 
> I thus assumed I wouldn't have to add a JTA implementation to the class
> path, but actually I'm getting a CNFE (see [1] for the complete trace):
> 
>ClassNotFoundException: Could not load requested class :
> com.arjuna.ats.jta.TransactionManager
> 
> Indeed Arjuna is what we use as TM by default. It is set by OGM's
> JtaPlatform implementation which in turn is used by transactions created by
> OGM's default TransactionFactory [2].
> 
> Unless I'm doing something wrong configuration-wise, I feel that requiring
> a JTA implementation for a non-transactional backend such as MongoDB is
> confusing and may make users ask whether OGM is doing the right thing.
> 
> Would it be feasible to to provide an "OGM local" TransactionImplementor +
> TransactionFactory to be used in such cases where the store does not
> support transactions (so no rollbacks etc.), but we'd "only" need a trigger
> for writing out changes to the datastore?
> 
> Any thoughts?
> 
> --Gunnar
> 
> [1] https://gist.github.com/gunnarmorling/ba193caecb7d5cdbd0a4
> [2]
> https://github.com/hibernate/hibernate-ogm/blob/master/core/src/main/java/org/hibernate/ogm/transaction/impl/OgmTransactionFactoryInitiator.java#L42
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] [OGM] Store objects as actual typed objects via the native grid format

[Gunnar Morling]

To me the user's problem appears to be that the POF approach mixes a data
type and its (de-)serialization logic within one class. Specifically, you
need to implement a Hazelcast interface to do so:

public class MyEntity implements Portable {

Long id;
String name;

...

@Override public void writePortable( PortableWriter writer ) throws
IOException { ... }
@Override public void readPortable( PortableReader reader ) throws
IOException { ... }
}

In my understanding that's where the request for passing the entity object
to the dialect as is comes from; without the actual entity available, you
can't get hold of the (de-)serialization routine needed to put the stuff
into the datastore and get it back.

IMO that'd not be the right approach, though. a) Implementing
store-specific interfaces in entities seems against the whole nature of OGM
(esp. when taking polyglot persistence into the picture), b) it circumvents
things such as @Column names, type conversion (which may be needed to
convert property types allowed by JPA but not naturally supported by the
store) etc.

So instead of letting the entity types implement Portable, the dialect
should deal with this. Question is how it can be done in a generic fashion
with the given APIs. Yes, there could be a single Portable implementation
employed by the dialect which can serialize a given entity tuple. But upon
read-back that generic implementation wouldn't know which properties to
read from the persisted stream.

One approach would be to automatically generate the Portable
implementations, based on the entity types present. Either up-front via
some kind of build plug-in or dynamically at runtime (it may be challenging
to ensure constant "class ids" required by portables). This approach could
be implemented with OGM as is, it only puts the burdens of schema
management etc. entirely to the dialect.

But I'd start like that, see how it flies and then examine how more logic
could be moved onto the OGM core side.

--Gunnar



2015-01-13 22:03 GMT+01:00 Sanne Grinovero :

> Many interesting ideas.
>
> Is the culprit not simply to be able to store the same entry into
> multiple (different) representations?
> I'd like to see the separation into "different representations" not
> being handled at the level of the dialect but higher up at level of
> OGM/ORM core, so that one could have - for example - some entities
> stored into a relational database, some other entities into MongoDB,
> and some entities into *both*.
> So configuration wise I'd have a section for each dialect, and then a
> way to tag each entity - possibly multiple times - to have then
> included into one of the configured databases.
>
> You'd have two consequences:
>  - you can have multiple instances of the same dialect type - for
> example two Coherence instances using a different POF encoding
> strategies
>  - the Query engine can pick the best strategy among all storage
> options, across both differences of representation into the same
> database but also across query technologies / capabilities
>
> @Entity @PersistenceGroup(“mongo-cluster-of-foos”, "cassandra-times")
> public Foo { … }
>
> A limitation is that I'd probably want to be able to mark various
> additional mapping annotations as belonging to a specific database
> only. For example I think a relation annotation like @ManyToOne should
> be the same on all - as it's related to the structure of the Java
> domain model - but other annotations such as @Column would need to
> have a qualifier so I can pick multiple different ones. The obvious
> solution is that such mapping solutions need to be externalized into
> mapping files (exclusively).
> In practice this might not be a too strong limitation, in all places
> I've worked the "@Column" annotation was the quick and dirty solution
> but people would prefer to make a corporate standard NamingStrategy
> which would consolidate such decisions out of the model.
>
> However you decide on those, the Query execution would need the smart
> planner we've fantasized about a bit.
>
> Somehow related: remember Adrian Nistor from the Infinispan team
> developed a mapping tool based on annotations to map POJOs to
> Protobuf. This is ready for general usage now, and could be useful
> here.
>
> -- Sanne
>
>
>
> On 13 January 2015 at 17:24, Emmanuel Bernard 
> wrote:
> >
> >> On 13 Jan 2015, at 18:06, Emmanuel Bernard 
> wrote:
> >>
> >> Note that the user here (see question c), also asks for the ability to
> denormalize the data and store a full object graph as one key and only a
> subset as a second key which is something we want to do but that we don’t
> have right now.
> >
> > Actually, even that could be done by an ad-hoc dialect which would store
> the full entity graph in one schema / cache and the normal (according to
> OGM) entity in another schema/cache. The Dialect does not give you the
> entity graph but since we now know how to batch work, we cou

Re: [hibernate-dev] [OGM] Transaction type "RESOURCE_LOCAL", still JTA is required

[Gunnar Morling]

2015-01-13 19:49 GMT+01:00 Steve Ebersole :

> You'd need to not specify the JtaPlatform service stuff.
>

Yes, but which org.hibernate.Transaction implementation to use? We'd need a
"fake" implementation which triggers the grid dialect upon flush()/commit()
invocations.

On Tue, Jan 13, 2015 at 12:18 PM, Gunnar Morling 
> wrote:
>
>> Hi,
>>
>> For a demo I have an OGM application which defines a persistence unit with
>> transaction type RESOURCE_LOCAL.
>>
>> I thus assumed I wouldn't have to add a JTA implementation to the class
>> path, but actually I'm getting a CNFE (see [1] for the complete trace):
>>
>> ClassNotFoundException: Could not load requested class :
>> com.arjuna.ats.jta.TransactionManager
>>
>> Indeed Arjuna is what we use as TM by default. It is set by OGM's
>> JtaPlatform implementation which in turn is used by transactions created
>> by
>> OGM's default TransactionFactory [2].
>>
>> Unless I'm doing something wrong configuration-wise, I feel that requiring
>> a JTA implementation for a non-transactional backend such as MongoDB is
>> confusing and may make users ask whether OGM is doing the right thing.
>>
>> Would it be feasible to to provide an "OGM local" TransactionImplementor +
>> TransactionFactory to be used in such cases where the store does not
>> support transactions (so no rollbacks etc.), but we'd "only" need a
>> trigger
>> for writing out changes to the datastore?
>>
>> Any thoughts?
>>
>> --Gunnar
>>
>> [1] https://gist.github.com/gunnarmorling/ba193caecb7d5cdbd0a4
>> [2]
>>
>> https://github.com/hibernate/hibernate-ogm/blob/master/core/src/main/java/org/hibernate/ogm/transaction/impl/OgmTransactionFactoryInitiator.java#L42
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] [OGM] Transaction type "RESOURCE_LOCAL", still JTA is required

[Gunnar Morling]

2015-01-14 9:27 GMT+01:00 Emmanuel Bernard :

> Probably. Needs exploring.
>

https://hibernate.atlassian.net/browse/OGM-718

Btw. why has OGM its own JTATransactionManagerTransaction instead of using
ORM's existing JtaTransaction?


> > On 13 Jan 2015, at 19:18, Gunnar Morling  wrote:
> >
> > Hi,
> >
> > For a demo I have an OGM application which defines a persistence unit
> with
> > transaction type RESOURCE_LOCAL.
> >
> > I thus assumed I wouldn't have to add a JTA implementation to the class
> > path, but actually I'm getting a CNFE (see [1] for the complete trace):
> >
> >ClassNotFoundException: Could not load requested class :
> > com.arjuna.ats.jta.TransactionManager
> >
> > Indeed Arjuna is what we use as TM by default. It is set by OGM's
> > JtaPlatform implementation which in turn is used by transactions created
> by
> > OGM's default TransactionFactory [2].
> >
> > Unless I'm doing something wrong configuration-wise, I feel that
> requiring
> > a JTA implementation for a non-transactional backend such as MongoDB is
> > confusing and may make users ask whether OGM is doing the right thing.
> >
> > Would it be feasible to to provide an "OGM local" TransactionImplementor
> +
> > TransactionFactory to be used in such cases where the store does not
> > support transactions (so no rollbacks etc.), but we'd "only" need a
> trigger
> > for writing out changes to the datastore?
> >
> > Any thoughts?
> >
> > --Gunnar
> >
> > [1] https://gist.github.com/gunnarmorling/ba193caecb7d5cdbd0a4
> > [2]
> >
> https://github.com/hibernate/hibernate-ogm/blob/master/core/src/main/java/org/hibernate/ogm/transaction/impl/OgmTransactionFactoryInitiator.java#L42
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] [OGM] Transaction type "RESOURCE_LOCAL", still JTA is required

[Emmanuel Bernard]

I don’t quite remember but looking at it, it looks like I needed something that 
would work on all cases: CMT or non CMT (excludes the use of UserTransaction), 
be able to start a transaction if none has been started already.
It’s rooted in https://hibernate.atlassian.net/browse/OGM-56 



> On 14 Jan 2015, at 10:10, Gunnar Morling  wrote:
> 
> 2015-01-14 9:27 GMT+01:00 Emmanuel Bernard  >:
> Probably. Needs exploring.
> 
> https://hibernate.atlassian.net/browse/OGM-718 
> 
> 
> Btw. why has OGM its own JTATransactionManagerTransaction instead of using 
> ORM's existing JtaTransaction?
> 
> 
> > On 13 Jan 2015, at 19:18, Gunnar Morling  > > wrote:
> >
> > Hi,
> >
> > For a demo I have an OGM application which defines a persistence unit with
> > transaction type RESOURCE_LOCAL.
> >
> > I thus assumed I wouldn't have to add a JTA implementation to the class
> > path, but actually I'm getting a CNFE (see [1] for the complete trace):
> >
> >ClassNotFoundException: Could not load requested class :
> > com.arjuna.ats.jta.TransactionManager
> >
> > Indeed Arjuna is what we use as TM by default. It is set by OGM's
> > JtaPlatform implementation which in turn is used by transactions created by
> > OGM's default TransactionFactory [2].
> >
> > Unless I'm doing something wrong configuration-wise, I feel that requiring
> > a JTA implementation for a non-transactional backend such as MongoDB is
> > confusing and may make users ask whether OGM is doing the right thing.
> >
> > Would it be feasible to to provide an "OGM local" TransactionImplementor +
> > TransactionFactory to be used in such cases where the store does not
> > support transactions (so no rollbacks etc.), but we'd "only" need a trigger
> > for writing out changes to the datastore?
> >
> > Any thoughts?
> >
> > --Gunnar
> >
> > [1] https://gist.github.com/gunnarmorling/ba193caecb7d5cdbd0a4 
> > 
> > [2]
> > https://github.com/hibernate/hibernate-ogm/blob/master/core/src/main/java/org/hibernate/ogm/transaction/impl/OgmTransactionFactoryInitiator.java#L42
> >  
> > 
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org 
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev 
> > 
> 
> 

___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] [OGM] Transaction type "RESOURCE_LOCAL", still JTA is required

[Emmanuel Bernard]

> On 14 Jan 2015, at 10:08, Gunnar Morling  wrote:
> 
> 2015-01-13 19:49 GMT+01:00 Steve Ebersole :
> 
>> You'd need to not specify the JtaPlatform service stuff.
>> 
> 
> Yes, but which org.hibernate.Transaction implementation to use? We'd need a
> "fake" implementation which triggers the grid dialect upon flush()/commit()
> invocations.

I think I originally replaced it so that it worked for Infinispan. Which 
mandates a JTA TM all the time (for transactions).
Looks like it was still working for the other datastores and no one bothered to 
improve a working bit until you discovered the extra dependency issue.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Naming and "naming strategies"

[Gunnar Morling]

> Do we need a contract for LogicalNamingStrategy?

As you say it's an internal concept only. Based on your description I don't
see why a user would want to customize it. So I'd internally make
consistently use of the LogicalNamingStrategy for resolving references, but
I'd not make it pluggable. Should someone really need this, it's easy to
make it pluggable later on.

> So I also propose to shift this to use that Identifier class

I like that idea.

Is it correct to say it represents a logical name basically? If so, how
about naming it "LogicalName"? "Identifier" seems too generic to me (e.g.
easily to be mixed up with entity identifiers). Would that class/interface
define a method String getPhysicalName()? That should nicely encapsulate
the quote handling.

> But is poses a problem when the same table name is used from different
schemas. [... ] 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. [...] that is
generally a restrictive limitation.  What are y'alls thoughts? Perhaps this
is one argument for allowing pluggable LogicalNamingStrategy?

I'd work with that restriction. I would not make LogicalNamingStrategy
pluggable just for this, until someone comes up with really compelling use
case why they'd need that sort of mapping.

--Gunnar


2015-01-13 19:43 GMT+01:00 Steve Ebersole :

> 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").

Re: [hibernate-dev] Naming and "naming strategies"

[Hardy Ferentschik]

Hi,

+1 for ImplicitNamingStrategy and PhysicalNamingStrategy
What would be the contract of these strategies?

I don't think LogicalNamingStrategy is necessary. I think this might 
just get too complicated for a user. Also, iiuc the logical name is for
internal lookups. 

+1 for actual identifier classes. I think the code would become easier to 
understand
and hopefully safer with these typed classes. I liked this approach when working
on the metamodel branch. I would, however, not make it an interface. I also see
this as a pre-mature optimisation

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

What exactly do you mean with 'selector'?

--Hardy



On Tue, Jan 13, 2015 at 12:43:37PM -0600, Steve Ebersole 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 

Re: [hibernate-dev] Naming and "naming strategies"

[Steve Ebersole]

>
> > So I also propose to shift this to use that Identifier class
>
> I like that idea.
>
> Is it correct to say it represents a logical name basically? If so, how
> about naming it "LogicalName"? "Identifier" seems too generic to me (e.g.
> easily to be mixed up with entity identifiers). Would that class/interface
> define a method String getPhysicalName()? That should nicely encapsulate
> the quote handling.
>

Well that depends on how we interpret "logical name".  Take a table named
"my_table" in the "my_schema" schema as part of the "my_catalog" catalog.
Now, each of those individual "names" would be an
* tableName = new Identifier( "my_table", false );
* schemaName = new Identifier( "my_schema", false );
* catalogName = new Identifier( "my_catalog", false );

So Identifier really just represents the parts of a "object name" (in SQL
terms).

Now historically, the logical name of a table is represented by this
qualified form.  Remember though that "historically" points specifically to
growing from hbm.xml  mapping where this is not really an issue.

As an aside, in that metamodel branch there is also an aggregated form to
represent the qualified table name by composing all 3 components together,
as well as physically grouping them into Schema objects.  But there is no
natural corollary to these concepts in org.hibernate.mapping, and so I will
not pull them over.  Although... I will say that it might be better to use
that typed form (QualifiedTableName class aggregating the 3 compoment
names) as the "cross reference key".
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Naming and "naming strategies"

[Steve Ebersole]

Something like:


public interface ImplicitNamingStrategy {
  public Identifier determinePrimaryTableName(ImplicitEntityNameSource
source);

  public Identifier determineJoinTableName(ImplicitJoinTableNameSource
source);

  public Identifier
determineCollectionTableName(ImplicitCollectionTableNameSource
source);

  public Identifier
determineDiscriminatorColumnName(ImplicitDiscriminatorColumnNameSource
source);

public Identifier
determineTenantIdColumnName(ImplicitTenantIdColumnNameSource
source);

  public Identifier
determineAttributeColumnName(ImplicitAttributeColumnNameSource
source);

  public Identifier
determineCollectionJoinColumnName(ImplicitCollectionJoinColumnNameSource
source);

...
}


The sources are simply parameter objects providing access to information
needed to determine the implicit name.  For example:

/**
 * Defines the source for entity naming.  Between legacy Hibernate
requirements and
 * JPA requirements this is, unfortunately, multi-sourced.  This contract
allows
 * access to all source values.
 *
 * @author Steve Ebersole
 */
public interface ImplicitEntityNamingSource {
/**
 * The FQN of the entity class.  Note, this may be {@code null} in the
case
 * of (non-JPA-compliant) dynamic entities).
  *
 * @return The entity class FQN, or {@code null} if a dynamic entity.
  */
  public String getEntityClassName();

  /**
 * Get the explicitly specified Hibernate entity name.  The Hibernate
name is
  * very much different from the JPA concept of entity name.
  *
  * @return The explicitly specified entity name
  */
  public String getExplicitEntityName();

  /**
  * The Hibernate entity name.  This might be either:
  * The explicitly specified entity name, if one
  * The unqualified entity class name if no entity name was
explicitly specified
  * 
  *
   * @return The Hibernate entity name
  */
  public String getEntityName();

  /**
 * The JPA-specific entity name.  See {@link
javax.persistence.Entity#name()} for details.
 *
  * @return The JPA entity name, if one was specified.  May return {@code
null} if one
  * was not explicitly specified.
  */
  public String getJpaEntityName();
}

etc...

And then:

public interface PhysicalNamingStrategy {
public Identifier toPhysicalCatalogName(Identifier name);

public Identifier toPhysicalSchemaName(Identifier name);

public Identifier toPhysicalTableName(Identifier name);

public Identifier toPhysicalColumnName(Identifier name);
}

I think ultimately it makes sense to pass some additional information
into PhysicalNamingStrategy to give access to Dialect, etc.

On Wed, Jan 14, 2015 at 4:38 AM, Hardy Ferentschik 
wrote:

> Hi,
>
> +1 for ImplicitNamingStrategy and PhysicalNamingStrategy
> What would be the contract of these strategies?
>
> I don't think LogicalNamingStrategy is necessary. I think this might
> just get too complicated for a user. Also, iiuc the logical name is for
> internal lookups.
>
> +1 for actual identifier classes. I think the code would become easier to
> understand
> and hopefully safer with these typed classes. I liked this approach when
> working
> on the metamodel branch. I would, however, not make it an interface. I
> also see
> this as a pre-mature optimisation
>
> > 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..
>
> What exactly do you mean with 'selector'?
>
> --Hardy
>
>
>
> On Tue, Jan 13, 2015 at 12:43:37PM -0600, Steve Ebersole 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 c

Re: [hibernate-dev] Naming and "naming strategies"

[Gunnar Morling]

2015-01-14 16:06 GMT+01:00 Steve Ebersole :

> > So I also propose to shift this to use that Identifier class
>>
>> I like that idea.
>>
>> Is it correct to say it represents a logical name basically? If so, how
>> about naming it "LogicalName"? "Identifier" seems too generic to me (e.g.
>> easily to be mixed up with entity identifiers). Would that class/interface
>> define a method String getPhysicalName()? That should nicely encapsulate
>> the quote handling.
>>
>
> Well that depends on how we interpret "logical name".  Take a table named
> "my_table" in the "my_schema" schema as part of the "my_catalog" catalog.
> Now, each of those individual "names" would be an
> * tableName = new Identifier( "my_table", false );
> * schemaName = new Identifier( "my_schema", false );
> * catalogName = new Identifier( "my_catalog", false );
>
> So Identifier really just represents the parts of a "object name" (in SQL
> terms).
>
> Now historically, the logical name of a table is represented by this
> qualified form.  Remember though that "historically" points specifically to
> growing from hbm.xml  mapping where this is not really an issue.
>
> As an aside, in that metamodel branch there is also an aggregated form to
> represent the qualified table name by composing all 3 components together,
> as well as physically grouping them into Schema objects.  But there is no
> natural corollary to these concepts in org.hibernate.mapping, and so I will
> not pull them over.  Although... I will say that it might be better to use
> that typed form (QualifiedTableName class aggregating the 3 compoment
> names) as the "cross reference key".
>

Yes, such an aggregated form indeed is how I had done it on first thought.
But then I don't really know the code which would be using it, so I cannot
comment on whether that'd be feasible or doable at this point of time.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Fwd: Hibernate ORM modules published as major.minor and an alias for main

[Emmanuel Bernard]

FYI

> Begin forwarded message:
> 
> Date: 14 Jan 2015 17:30:59 CET
> From: Scott Marlow 
> To: Emmanuel Bernard 
> Subject: Re: Hibernate ORM modules published as major.minor and an alias for 
> main
> 
> Hi Emmanuel,
> 
> On 01/14/2015 11:06 AM, Emmanuel Bernard wrote:
>> Hi Scott,
>> 
>> In the f2f we discussed the idea of having ORM being published as 
>> major.minor and have an alias form main to the default WildFly targeted 
>> version.
>> Is that in and for which WildFly version?
> 
> I created https://issues.jboss.org/browse/WFLY-4021 and 
> https://github.com/wildfly/wildfly/pull/6883 which got merged into WildFly 
> 9.0.
> 
> The change is that modules/system/layers/base/org/hibernate/4.3/module.xml 
> was added and contains:
> "
>  slot="4.3" target-name="org.hibernate"/>
> "
> 
> I think this is wrong though, as it should be:
> 
> "
>  target-name="org.hibernate"/>
> "
> 
> I'll reopen and push a new pull request.
> 
> 
>> 
>> I am just trying the catch up.
>> 

___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Naming and "naming strategies"

[Gunnar Morling]

2015-01-14 16:19 GMT+01:00 Steve Ebersole :

> Something like:
>
>
> public interface ImplicitNamingStrategy {
>   public Identifier determinePrimaryTableName(ImplicitEntityNameSource
> source);
>
>   public Identifier determineJoinTableName(ImplicitJoinTableNameSource
> source);
>
>   public Identifier
> determineCollectionTableName(ImplicitCollectionTableNameSource
> source);
>
>   public Identifier
> determineDiscriminatorColumnName(ImplicitDiscriminatorColumnNameSource
> source);
>
> public Identifier
> determineTenantIdColumnName(ImplicitTenantIdColumnNameSource
> source);
>
>   public Identifier
> determineAttributeColumnName(ImplicitAttributeColumnNameSource
> source);
>
>   public Identifier
> determineCollectionJoinColumnName(ImplicitCollectionJoinColumnNameSource
> source);
>
> ...
> }
>
>
> The sources are simply parameter objects providing access to information
> needed to determine the implicit name.  For example:
>
> /**
>  * Defines the source for entity naming.  Between legacy Hibernate
> requirements and
>  * JPA requirements this is, unfortunately, multi-sourced.  This contract
> allows
>  * access to all source values.
>  *
>  * @author Steve Ebersole
>  */
> public interface ImplicitEntityNamingSource {
> /**
>  * The FQN of the entity class.  Note, this may be {@code null} in the
> case
>  * of (non-JPA-compliant) dynamic entities).
>   *
>  * @return The entity class FQN, or {@code null} if a dynamic entity.
>   */
>   public String getEntityClassName();
>
>   /**
>  * Get the explicitly specified Hibernate entity name.  The Hibernate
> name is
>   * very much different from the JPA concept of entity name.
>   *
>   * @return The explicitly specified entity name
>   */
>   public String getExplicitEntityName();
>
>   /**
>   * The Hibernate entity name.  This might be either:
>   * The explicitly specified entity name, if one
>   * The unqualified entity class name if no entity name was
> explicitly specified
>   * 
>   *
>* @return The Hibernate entity name
>   */
>   public String getEntityName();
>
>   /**
>  * The JPA-specific entity name.  See {@link
> javax.persistence.Entity#name()} for details.
>  *
>   * @return The JPA entity name, if one was specified.  May return {@code
> null} if one
>   * was not explicitly specified.
>   */
>   public String getJpaEntityName();
> }
>
> etc...
>
> And then:
>
> public interface PhysicalNamingStrategy {
> public Identifier toPhysicalCatalogName(Identifier name);
>
> public Identifier toPhysicalSchemaName(Identifier name);
>
> public Identifier toPhysicalTableName(Identifier name);
>
> public Identifier toPhysicalColumnName(Identifier name);
> }
>
>
So why is PhysicalNamingStrategy returning Identifiers and not Strings? I
think I find the double usage of Identifier for logical names (or
"components" thereof) and physical names somewhat irritating. As the
physical name I'd have expected just the "rendered" String as to be passed
to the driver.

I think ultimately it makes sense to pass some additional information
> into PhysicalNamingStrategy to give access to Dialect, etc.
>

Interesting; As we had already discussed recently, that raises the question
of how to evolve the interface in a compatible way.

Java 8's default methods of course help, but until we can rely on that, I
find using abstract classes rather than interfaces attractive for such
contracts. With these, a method such as void
initialize(SomeInitializationContext) can be easily added, and
implementations can override it in a future version if they wish. Or you
foresee some sort of context parameter on the actual methods of the
contract.


>
> On Wed, Jan 14, 2015 at 4:38 AM, Hardy Ferentschik 
> wrote:
>
> > Hi,
> >
> > +1 for ImplicitNamingStrategy and PhysicalNamingStrategy
> > What would be the contract of these strategies?
> >
> > I don't think LogicalNamingStrategy is necessary. I think this might
> > just get too complicated for a user. Also, iiuc the logical name is for
> > internal lookups.
> >
> > +1 for actual identifier classes. I think the code would become easier to
> > understand
> > and hopefully safer with these typed classes. I liked this approach when
> > working
> > on the metamodel branch. I would, however, not make it an interface. I
> > also see
> > this as a pre-mature optimisation
> >
> > > 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..
> >
> > What exactly do you mean with 'selector'?
> >
> > --Hardy
> >
> >
> >
> > On Tue, Jan 13, 2015 at 12:43:37PM -0600, Steve Ebersole 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 

Re: [hibernate-dev] Naming and "naming strategies"

[Steve Ebersole]

On Wed, Jan 14, 2015 at 11:14 AM, Gunnar Morling 
wrote:

> 2015-01-14 16:19 GMT+01:00 Steve Ebersole :
>
>> Something like:
>>
>>
>> public interface ImplicitNamingStrategy {
>>   public Identifier determinePrimaryTableName(ImplicitEntityNameSource
>> source);
>>
>>   public Identifier determineJoinTableName(ImplicitJoinTableNameSource
>> source);
>>
>>   public Identifier
>> determineCollectionTableName(ImplicitCollectionTableNameSource
>> source);
>>
>>   public Identifier
>> determineDiscriminatorColumnName(ImplicitDiscriminatorColumnNameSource
>> source);
>>
>> public Identifier
>> determineTenantIdColumnName(ImplicitTenantIdColumnNameSource
>> source);
>>
>>   public Identifier
>> determineAttributeColumnName(ImplicitAttributeColumnNameSource
>> source);
>>
>>   public Identifier
>> determineCollectionJoinColumnName(ImplicitCollectionJoinColumnNameSource
>> source);
>>
>> ...
>> }
>>
>>
>> The sources are simply parameter objects providing access to information
>> needed to determine the implicit name.  For example:
>>
>> /**
>>  * Defines the source for entity naming.  Between legacy Hibernate
>> requirements and
>>  * JPA requirements this is, unfortunately, multi-sourced.  This contract
>> allows
>>  * access to all source values.
>>  *
>>  * @author Steve Ebersole
>>  */
>> public interface ImplicitEntityNamingSource {
>> /**
>>  * The FQN of the entity class.  Note, this may be {@code null} in the
>> case
>>  * of (non-JPA-compliant) dynamic entities).
>>   *
>>  * @return The entity class FQN, or {@code null} if a dynamic entity.
>>   */
>>   public String getEntityClassName();
>>
>>   /**
>>  * Get the explicitly specified Hibernate entity name.  The Hibernate
>> name is
>>   * very much different from the JPA concept of entity name.
>>   *
>>   * @return The explicitly specified entity name
>>   */
>>   public String getExplicitEntityName();
>>
>>   /**
>>   * The Hibernate entity name.  This might be either:
>>   * The explicitly specified entity name, if one
>>   * The unqualified entity class name if no entity name was
>> explicitly specified
>>   * 
>>   *
>>* @return The Hibernate entity name
>>   */
>>   public String getEntityName();
>>
>>   /**
>>  * The JPA-specific entity name.  See {@link
>> javax.persistence.Entity#name()} for details.
>>  *
>>   * @return The JPA entity name, if one was specified.  May return {@code
>> null} if one
>>   * was not explicitly specified.
>>   */
>>   public String getJpaEntityName();
>> }
>>
>> etc...
>>
>> And then:
>>
>> public interface PhysicalNamingStrategy {
>> public Identifier toPhysicalCatalogName(Identifier name);
>>
>> public Identifier toPhysicalSchemaName(Identifier name);
>>
>> public Identifier toPhysicalTableName(Identifier name);
>>
>> public Identifier toPhysicalColumnName(Identifier name);
>> }
>>
>>
> So why is PhysicalNamingStrategy returning Identifiers and not Strings? I
> think I find the double usage of Identifier for logical names (or
> "components" thereof) and physical names somewhat irritating. As the
> physical name I'd have expected just the "rendered" String as to be passed
> to the driver.
>

First, technically, the "physical" name (the one we send to the database)
needs to be qualified.  So if this is really resolving to that level, we'd
actually need to have:

public interface PhysicalNamingStrategy {
public Identifier toPhysicalTableName(Identifier catalog, Identifier
schema, Identifier table);

public Identifier toPhysicalColumnName(Identifier name);
}

So you think the naming strategy that is supplied by the user should be the
thing that interprets Dialect-specific quoting, Dialect-specific
qualifying, etc?  For example, consider:

Identifier catalogName = new Identifier( "some_catalog", true );
Identifier schemaName = new Identifier( "some_schema", true );
Identifier tableName = new Identifier( "some_table", true );
String physicalName =
physicalNamingStrategy.toPhysicalTableName(catalogName, schemaName,
tableName );

Do you really think it is best design to have PhysicalNamingStrategy (quite
often a user-supplied impl) have to deal with Dialect differences in
qualifying names and quoting names?  Aka, is it really the best design to
have users have to understand to return:
1) "some_schema"."some_table"@"some_catalog" - for Oracle
2) [some_catalog].[some_schema].[some_table] - for SQLServer
3) etc...

IMO it is better to simply have PhysicalNamingStrategy deal with each
component, and then the Hibernate code that calls PhysicalNamingStrategy be
the one that renders them to a properly qualified String:

Identifier catalogName = new Identifier( "some_catalog", true );
Identifier schemaName = new Identifier( "some_schema", true );
Identifier tableName = new Identifier( "some_table", true );

Identifier physicalCatalogName =
physicalNamingStrategy.toPhysicalCatalogName(catalogName);
Identifier physicalSchemaName =
physicalNamingStrategy.toPhysicalSc