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

[Sanne Grinovero]

On 15 January 2015 at 16:01, Emmanuel Bernard  wrote:
>
> 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 ;)

Uhm it's annoying that the file would move in git indeed. But is that
a requirement of the modules system or is that a convention which we
could challenge/refine?

For technical reasons it's obviously better to be able to pick a
specific version than not being able to; for example OGM requires a
specific version of ORM, and "4.3" is not good enough to make sure
we're using the right one. The current solution is working because
we're building against a specific Wildfly / EAP version and build the
modules taking advantage of our knowledge of the specific versions
we'll encounter in there, but it's getting more complex quickly.

I understand that some people will be happy enough to state they
depend on "ORM 4.3" rather than "ORM 4.2" and having you drop-in micro
updates as convenient. In *theory* we promise full drop-in backwards
compatibility on the micro version so we should be able to expect a
user to just need to specify the major.minor, but there's the
possibility of unintentionally breaking this promise (a bug) or - as
historical facts - either OGM or Search needing a specific version.

Sometimes it's just more practical for us to break our "internal
contracts" even in a micro release, to move on timely; in this case we
require a specific micro of ORM even though the exposed contract to
end users and other integrators is still backwards compatible.

So I think it would be better to have both module representations
(major.minor and major.minor.micro): we'd consider the .micro
variation as something people shouldn't use unless they have a
specific need.. but it's good to be able to use it when such a
specific need arises.
Still if that's too inconvenient, just having the major.minor would be
an improvement on current state :)

No other project raised such needs on the WildFly mailing list?
(except Infinispan, which is in our same needs)

Sanne
___
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 16 Jan 2015, at 13:58, Sanne Grinovero  wrote:
> 
> On 15 January 2015 at 16:01, Emmanuel Bernard  > wrote:
>> 
>> 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 ;)
> 
> Uhm it's annoying that the file would move in git indeed. But is that
> a requirement of the modules system or is that a convention which we
> could challenge/refine?
> 
> For technical reasons it's obviously better to be able to pick a
> specific version than not being able to; for example OGM requires a
> specific version of ORM, and "4.3" is not good enough to make sure
> we're using the right one. The current solution is working because
> we're building against a specific Wildfly / EAP version and build the
> modules taking advantage of our knowledge of the specific versions
> we'll encounter in there, but it's getting more complex quickly.
> 
> I understand that some people will be happy enough to state they
> depend on "ORM 4.3" rather than "ORM 4.2" and having you drop-in micro
> updates as convenient. In *theory* we promise full drop-in backwards
> compatibility on the micro version so we should be able to expect a
> user to just need to specify the major.minor, but there's the
> possibility of unintentionally breaking this promise (a bug) or - as
> historical facts - either OGM or Search needing a specific version.
> 
> Sometimes it's just more practical for us to break our "internal
> contracts" even in a micro release, to move on timely; in this case we
> require a specific micro of ORM even though the exposed contract to
> end users and other integrators is still backwards compatible.
> 
> So I think it would be better to have both module representations
> (major.minor and major.minor.micro): we'd consider the .micro
> variation as something people shouldn't use unless they have a
> specific need.. but it's good to be able to use it when such a
> specific need arises.
> Still if that's too inconvenient, just having the major.minor would be
> an improvement on current state :)
> 
> No other project raised such needs on the WildFly mailing list?
> (except Infinispan, which is in our same needs)

So let’s assume that WF 8.1.0 pushes ORM 4.3.4 and WF 8.1.1 pushes ORM 4.3.6.
And let’s assume that OGM 4.1.0 uses ORM 4.3.4 and OGM 4.1.1 uses ORM 4.3.6 
(due to the issues you describe above).

If you put the major.minor.micro in WF with aliases for major.minor and main, 
does that really help OGM?
1. if WF 8.1.1 does not keep ORM 4.3.4 around, then I would say no. As OGM 
module provider, you still need to know that a given WF version has the right 
version or not.
2. if WF 8.1.1 does keep the old ORM versions around (i.e. ship 4.3.4 and 
4.3.6), then still OGM does not know if the exact version of ORM is included.

The only solution I can think of is for OGM to also bundle the minimal ORM 
major.minor.micro it needs and have a way to ask the module system to use the 
most recent between that one and the WF one. I don’t think the module system 
offers than and I think they are against version range for a lot of reasons.

So turning the table, how does your solution solve or improve the problem Sanne?
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

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

[Emmanuel Bernard]

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.

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?

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

+1 to enforce that a table name must be unique for a given entity across all 
catalogs/schemas.

Emmanuel

> On 13 Jan 2015, at 19:43, 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

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

[Steve Ebersole]

On Fri, Jan 16, 2015 at 7:32 AM, Emmanuel Bernard 
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

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

[Steve Ebersole]

On Fri, Jan 16, 2015 at 8:10 AM, Steve Ebersole  wrote:
>
> 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.
>

Also, we want to be very careful with stuff like "all lower naming rule".
For example, think of JPA's "quote all identifiers" setting.  In fact, to
circle back to a question Gunnar asked, this is one of the reasons I want
to have PhysicalNamingStrategy accept Identifier (with quoted/unquoted
flag) and return Identifier.
___
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]

On Fri, Jan 16, 2015 at 8:10 AM, Steve Ebersole  wrote:
>
>
>> 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.
>

I just wanted to clarify here a bit.  As far as I know, the only time that
this could be a problem is when we need @Column to refer to the primary
table and the name of the primary table is implicit.  But JPA designs for
that by saying that @Column is expected to refer to the primary table when
@Column#table is null or not specified.  What I was saying above was this,
imo, it is not a reasonable for this to work:

@Entity
public Customer {
@Column( ..., table="Customer" )
...
}

I just think that makes no sense.

Am I missing any potential uses where @Column#table would refer to
something that might reasonably be implicit?
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

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

[Emmanuel Bernard]

> On 16 Jan 2015, at 18:37, Steve Ebersole  wrote:
> 
> On Fri, Jan 16, 2015 at 8:10 AM, Steve Ebersole  > wrote:
> 
> 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.
> 
> I just wanted to clarify here a bit.  As far as I know, the only time that 
> this could be a problem is when we need @Column to refer to the primary table 
> and the name of the primary table is implicit.  But JPA designs for that by 
> saying that @Column is expected to refer to the primary table when 
> @Column#table is null or not specified.  What I was saying above was this, 
> imo, it is not a reasonable for this to work:
> 
> @Entity
> public Customer {
> @Column( ..., table="Customer" )
> ...
> }
> 
> I just think that makes no sense.
> 
> Am I missing any potential uses where @Column#table would refer to something 
> that might reasonably be implicit?
> 

No but it might be more problematic for `@JoinColumn(name=“customer_fk, 
referencedColumnName=“id”)` where the referenced entity has `@Id String id`. 
That family of references might be more common than secondary tables.
___
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]

In my opinion, this blend of implicit naming and explicit naming is just
asking for problems.  But to answer your specific question, yes.. altering
the naming stratagies used could conceivably mess up cross referencing in
cases like this.
On Jan 16, 2015 12:09 PM, "Emmanuel Bernard"  wrote:

>
> On 16 Jan 2015, at 18:37, Steve Ebersole  wrote:
>
> On Fri, Jan 16, 2015 at 8:10 AM, Steve Ebersole 
> wrote:
>>
>>
>>> 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.
>>
>
> I just wanted to clarify here a bit.  As far as I know, the only time that
> this could be a problem is when we need @Column to refer to the primary
> table and the name of the primary table is implicit.  But JPA designs for
> that by saying that @Column is expected to refer to the primary table when
> @Column#table is null or not specified.  What I was saying above was this,
> imo, it is not a reasonable for this to work:
>
> @Entity
> public Customer {
> @Column( ..., table="Customer" )
> ...
> }
>
> I just think that makes no sense.
>
> Am I missing any potential uses where @Column#table would refer to
> something that might reasonably be implicit?
>
>
> No but it might be more problematic for `@JoinColumn(name=“customer_fk,
> referencedColumnName=“id”)` where the referenced entity has `@Id String
> id`. That family of references might be more common than secondary tables.
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev