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

[Sanne Grinovero]

Hi Scott,
I'm not sure I completely understood your email, but from the example
it looks like you're having the alias relation in the opposite
direction.

We would need to have the actual jars into a module which has the
precise identifier, to match exactly the jars it contains.
Then we'd add an alias to specify that the "main" slot is the specific version.

For example:

## Actual Module



<

   ...


## The alias


By using this structure you can allow most applications to simply
depend on "org.hibernate" at slot "main". This is useful for the
majority of users, who know they want to depend on Hibernate and are
not too fuzzy about the version they use, or simply want the
"recommended" version, which is essentially what you decide is by
pulling upgrades into WildFly.

But some of our frameworks who might need to depend on a specific
version of ORM would have the option to explicitly depend on
"org.hibernate" slot "4.3.8.Final", which is what we occasionally
need.
Also this would make it possible for the ORM project to release
"update packs", say a version 4.3.9.Final is released soon: users
would be able to drop this into their application server using slot
"4.3.9.Final" without risking to break other applications.

We could also be a bit more fine-grained: are you still keeping
Hibernate 3 around in WildFly 9?
If yes, you might want to have a structure like this one:

## Actual Module




   ...


## The 4.x alias


## The main alias


One could also think of introducing a 4.3.x level.. possibilities are
endless but the priority for us would be to be able to call out a
specific version.

Thanks,
Sanne



On 14 January 2015 at 17:12, Emmanuel Bernard  wrote:
> 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
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

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

[Scott Marlow]

The change I mentioned for WFLY-4021, is merged in for WildFly 9.0.

On 01/15/2015 07:42 AM, Sanne Grinovero wrote:
> Hi Scott,
> I'm not sure I completely understood your email, but from the example
> it looks like you're having the alias relation in the opposite
> direction.

The WFLY-4021 change allows an application to depend on a specific 
major.minor version of Hibernate ORM:



>
> We would need to have the actual jars into a module which has the
> precise identifier, to match exactly the jars it contains.
> Then we'd add an alias to specify that the "main" slot is the specific 
> version.

When we talked at the f2f, I said that we would do major.minor, I think 
that is the summary notes from the discussion.

If we were to reverse the definitions, so that org.hibernate:main is an 
alias for a specific version of ORM (whether its using major.minor or 
major.minor.micro, it makes no difference to me) and that offers the 
advantages that your thinking of.

Something to keep in mind, in this multiple ORM version world, is that 
the static javax.persistence api is not aware of modules currently.  By 
the fact that WildFly always loads org.hibernate:main first, 
org.hibernate:main is always first in the list returned by 
PersistenceProviderResolver.getPersistenceProviders().  In the module 
aware (container) deployment code in WildFly, we do check if the 
persistence unit specifies a jboss.as.jpa.providerModule property and 
use that to load the persistence provider from the specified module.


>
> For example:
>
> ## Actual Module
> 
>  
>  
>  <
>  
> ...
> 
>
> ## The alias
>   name="org.hibernate" slot="main"
>  target-name="org.hibernate" target-slot="4.3.8.Final" />
>
> By using this structure you can allow most applications to simply
> depend on "org.hibernate" at slot "main". This is useful for the
> majority of users, who know they want to depend on Hibernate and are
> not too fuzzy about the version they use, or simply want the
> "recommended" version, which is essentially what you decide is by
> pulling upgrades into WildFly.
>
> But some of our frameworks who might need to depend on a specific
> version of ORM would have the option to explicitly depend on
> "org.hibernate" slot "4.3.8.Final", which is what we occasionally
> need.
> Also this would make it possible for the ORM project to release
> "update packs", say a version 4.3.9.Final is released soon: users
> would be able to drop this into their application server using slot
> "4.3.9.Final" without risking to break other applications.
>
> We could also be a bit more fine-grained: are you still keeping
> Hibernate 3 around in WildFly 9?

My plan was to remove the Hibernate 3 integration code.  I started doing 
that about a year ago or so, on a WildFly branch that (almost) works 
against Hibernate master from back then.  That branch is very dusty now.

Is there going to be a stable ORM 5.0 branch soon?  At some point, we 
can resume integrating Jipijapa with ORM 5.0 and integrating that with 
WildFly (not sure if that will be WildFly 9 or 10).


> If yes, you might want to have a structure like this one:
>
> ## Actual Module
> 
>  
>  
>  
> ...
> 
>
> ## The 4.x alias
>   name="org.hibernate" slot="4.x"
>  target-name="org.hibernate" target-slot="4.3.8.Final" />
>
> ## The main alias
>   name="org.hibernate" slot="main"
>  target-name="org.hibernate" target-slot="4.x" />
>
> One could also think of introducing a 4.3.x level.. possibilities are
> endless but the priority for us would be to be able to call out a
> specific version.
>
> Thanks,
> Sanne
>
>
>
> On 14 January 2015 at 17:12, Emmanuel Bernard  wrote:
>> 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] Fwd: Hibernate ORM modules published as major.minor and an alias for main

[Steve Ebersole]

master is that branch.  But remember that we pulled back the scope for 5.0.


On Thu, Jan 15, 2015 at 7:56 AM, Scott Marlow  wrote:

> The change I mentioned for WFLY-4021, is merged in for WildFly 9.0.
>
> On 01/15/2015 07:42 AM, Sanne Grinovero wrote:
> > Hi Scott,
> > I'm not sure I completely understood your email, but from the example
> > it looks like you're having the alias relation in the opposite
> > direction.
>
> The WFLY-4021 change allows an application to depend on a specific
> major.minor version of Hibernate ORM:
>
> 
>
> >
> > We would need to have the actual jars into a module which has the
> > precise identifier, to match exactly the jars it contains.
> > Then we'd add an alias to specify that the "main" slot is the specific
> version.
>
> When we talked at the f2f, I said that we would do major.minor, I think
> that is the summary notes from the discussion.
>
> If we were to reverse the definitions, so that org.hibernate:main is an
> alias for a specific version of ORM (whether its using major.minor or
> major.minor.micro, it makes no difference to me) and that offers the
> advantages that your thinking of.
>
> Something to keep in mind, in this multiple ORM version world, is that
> the static javax.persistence api is not aware of modules currently.  By
> the fact that WildFly always loads org.hibernate:main first,
> org.hibernate:main is always first in the list returned by
> PersistenceProviderResolver.getPersistenceProviders().  In the module
> aware (container) deployment code in WildFly, we do check if the
> persistence unit specifies a jboss.as.jpa.providerModule property and
> use that to load the persistence provider from the specified module.
>
>
> >
> > For example:
> >
> > ## Actual Module
> >  slot="4.3.8.Final">
> >  
> >  
> >  <
> >  
> > ...
> > 
> >
> > ## The alias
> >  >  name="org.hibernate" slot="main"
> >  target-name="org.hibernate" target-slot="4.3.8.Final" />
> >
> > By using this structure you can allow most applications to simply
> > depend on "org.hibernate" at slot "main". This is useful for the
> > majority of users, who know they want to depend on Hibernate and are
> > not too fuzzy about the version they use, or simply want the
> > "recommended" version, which is essentially what you decide is by
> > pulling upgrades into WildFly.
> >
> > But some of our frameworks who might need to depend on a specific
> > version of ORM would have the option to explicitly depend on
> > "org.hibernate" slot "4.3.8.Final", which is what we occasionally
> > need.
> > Also this would make it possible for the ORM project to release
> > "update packs", say a version 4.3.9.Final is released soon: users
> > would be able to drop this into their application server using slot
> > "4.3.9.Final" without risking to break other applications.
> >
> > We could also be a bit more fine-grained: are you still keeping
> > Hibernate 3 around in WildFly 9?
>
> My plan was to remove the Hibernate 3 integration code.  I started doing
> that about a year ago or so, on a WildFly branch that (almost) works
> against Hibernate master from back then.  That branch is very dusty now.
>
> Is there going to be a stable ORM 5.0 branch soon?  At some point, we
> can resume integrating Jipijapa with ORM 5.0 and integrating that with
> WildFly (not sure if that will be WildFly 9 or 10).
>
>
> > If yes, you might want to have a structure like this one:
> >
> > ## Actual Module
> >  slot="4.3.8.Final">
> >  
> >  
> >  
> > ...
> > 
> >
> > ## The 4.x alias
> >  >  name="org.hibernate" slot="4.x"
> >  target-name="org.hibernate" target-slot="4.3.8.Final" />
> >
> > ## The main alias
> >  >  name="org.hibernate" slot="main"
> >  target-name="org.hibernate" target-slot="4.x" />
> >
> > One could also think of introducing a 4.3.x level.. possibilities are
> > endless but the priority for us would be to be able to call out a
> > specific version.
> >
> > Thanks,
> > Sanne
> >
> >
> >
> > On 14 January 2015 at 17:12, Emmanuel Bernard 
> wrote:
> >> 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

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

[Steve Ebersole]

So here ( I think) is a better way to categorize these terms/concepts:

   1. logical name - the "raw" name for a table or column (or schema or
   catalog).  Think along of the lines of the concept of a *logical* domain
   model in terms of a parallel.
   1. explicit logical name - the logical name is explicitly specified in
  the mapping
  2. implicit logical name - the logical name is determined via
  ImplicitNamingStrategy
   2. physical name - The name for a table or column (or schema or catalog)
   as it appears in the database.  This is the logical name with rules applied
   for quoting, identifier length restrictions, etc as controlled by the
   PhysicalNamingStrategy

The above relates specifically to unqualified forms, aka Identifiers. A
qualified name, then, is an aggregation of identifiers such as:

class QualifiedSchemaName {
Identifier catalogName;
Identifier schemaName;
}

class QualifiedTableName {
QualifiedSchemaName schemaName;
Identifier tableName;
}

class QualifiedConstraintName {
QualifiedSchemaName schemaName;
Identifier constraintName;
}

class QualifiedColumnName {
QualifiedTableName tableName;
Identifier columnName;
}

There is nothing intrinsically logical or physical about the Identifier or
Qualified* classes.  They can represent both.

Hopefully this helps clarify


On Wed, Jan 14, 2015 at 3:20 PM, Steve Ebersole  wrote:

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

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

[Emmanuel Bernard]

> On 15 Jan 2015, at 14:56, Scott Marlow  wrote:
> 
> When we talked at the f2f, I said that we would do major.minor, I think 
> that is the summary notes from the discussion.
> 
> If we were to reverse the definitions, so that org.hibernate:main is an 
> alias for a specific version of ORM (whether its using major.minor or 
> major.minor.micro, it makes no difference to me) and that offers the 
> advantages that your thinking of.

I think what Sanne propose is what he and I had in mind when we discussed at 
the f2f. I think it makes a bit more sense.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

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

[Scott Marlow]

On 01/15/2015 09:49 AM, Emmanuel Bernard wrote:
>
>> On 15 Jan 2015, at 14:56, Scott Marlow > > wrote:
>>
>> When we talked at the f2f, I said that we would do major.minor, I think
>> that is the summary notes from the discussion.
>>
>> If we were to reverse the definitions, so that org.hibernate:main is an
>> alias for a specific version of ORM (whether its using major.minor or
>> major.minor.micro, it makes no difference to me) and that offers the
>> advantages that your thinking of.
>
> I think what Sanne propose is what he and I had in mind when we
> discussed at the f2f. I think it makes a bit more sense.

I think that this is some sort of minimal/maximal regular expressing 
matching thing.

When we discussed this at the f2f meeting, I was thinking of the minimal 
way to do what you wanted and thought we were in sync.  Now, I 
understand the additional part of what you wanted (more of a maximal 
match).   :)

I think the simple change, is to invert the modules, like suggested. 
Such that org.hibernate:main is an alias that points to a real module.

The part that I am unsure about is including the micro version in the 
module path, which means that every release of WildFly that includes an 
upgraded Hibernate, will likely have the jars in a different path (could 
be a pain for any configuration settings that point to the Hibernate jars).

The actual module path would also move around a lot in git, which is 
annoying but I have no real complaints about that.

One question is how will the different actual "4.3.micro" modules be 
created?  Would external tools automate that or the user manually create 
them (copy all of the Hibernate jars in, setup a module.xml and 
reference needed dependencies)?

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

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

[Emmanuel Bernard]

> On 15 Jan 2015, at 16:54, Scott Marlow  wrote:
> 
> 
> The part that I am unsure about is including the micro version in the module 
> path, which means that every release of WildFly that includes an upgraded 
> Hibernate, will likely have the jars in a different path (could be a pain for 
> any configuration settings that point to the Hibernate jars).
> 
> The actual module path would also move around a lot in git, which is annoying 
> but I have no real complaints about that.

On that I am neutral. I remember Sanne advocated this but I forgot the rational 
nor if I was convinced ;)
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev