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

To clarify... The same NamingStrategy is used no matter what by default. The variance comes from the fact that each binding method calls different methods :( Which of course makes retrofitting tough in these cases. The main use case I have seen where this happens is in many-to-one mappings. Hb

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

See below... On Mon, Feb 23, 2015 at 3:33 AM, Emmanuel Bernard wrote: > Which one do you intend being the default? > In 4.x AFAIR, it was > > * ImplicitNamingStrategyLegacyHbmImpl's behavior if you started ORM with > the classic APIs. > * ImplicitNamingStrategyLegacyJpaImpl's behavior if you sta

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

Which one do you intend being the default? In 4.x AFAIR, it was * ImplicitNamingStrategyLegacyHbmImpl's behavior if you started ORM with the classic APIs. * ImplicitNamingStrategyLegacyJpaImpl's behavior if you started ORM via the JPA APIS (or was it ImplicitNamingStrategyStandardImpl?) About n

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

So at the moment I have the following ImplicitNamingStrategy impls: 1) ImplicitNamingStrategyStandardImpl - Which is compliant with the rules set forth in the JPA standard 2) ImplicitNamingStrategyLegacyJpaImpl - Which implements the initial support done for JPA 1, before JPA 2 clarified some thin

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

I’d say +1 for adding coverage of them in the implicit naming strategy. > On 02 Feb 2015, at 19:16, Steve Ebersole wrote: > > They do not. HBM, e.g., uses "idx" for map keys columns as well as > list/array index columns. JPA says to use {attribute-name}_ORDER for list > index column. Unless

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

Hi, > > Also, you might think about embedded objects. I think today the implicit > > contract received the qualified property names separated by dots > > e.g. “homeAddress.street”. should that continue as it is or is there a need > > for abstraction? > > > > This is already handled well IMO. The

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

They do not. HBM, e.g., uses "idx" for map keys columns as well as list/array index columns. JPA says to use {attribute-name}_ORDER for list index column. Unless I missed it (which is completely possible in annotation binding) we always use the JPA-defined default in those cases rather than usin

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

> On 02 Feb 2015, at 17:51, Steve Ebersole wrote: > > On Mon, Feb 2, 2015 at 8:34 AM, Emmanuel Bernard > wrote: > > I think you’re missing things like @MapKeyColumn, @OrderColumn > > So that's a good discussion. These are things that have previously been > ha

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

On Mon, Feb 2, 2015 at 8:34 AM, Emmanuel Bernard wrote: I think you’re missing things like @MapKeyColumn, @OrderColumn > So that's a good discussion. These are things that have previously been hard-coded defaults (at least on hbm side) and therefore had no specific naming strategy hooks. I'm a

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

I think you’re missing things like @MapKeyColumn, @OrderColumn Also, you might think about embedded objects. I think today the implicit contract received the qualified property names separated by dots e.g. “homeAddress.street”. should that continue as it is or is there a need for abstraction? E

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

So here is what I have for implicit naming strategy, in simplified form: 1. Table naming 1. Entity primary table - @Table 2. Join table - @JoinTable 3. Collection table - @CollectionTable 4. 2. Column naming 1. basic attribute column 2. entity discrimina

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

Thanks Max for validating I am not going insane... at least in regards to this :) On Fri, Jan 23, 2015 at 10:19 AM, Max Rydahl Andersen wrote: > On 23 Jan 2015, at 14:18, Steve Ebersole wrote: > > [1] - I vaguely recall seeing that certain databases allow different >> length >> constraints for

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

On 23 Jan 2015, at 14:18, Steve Ebersole wrote: > [1] - I vaguely recall seeing that certain databases allow different > length > constraints for different types of identifiers (table name, versus > column > name, versus constrain name, ...). Can anyone confirm that? I remember db2 have this f

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

Another thing to consider here... In regards to physical naming, one of the aspects we need to consider is to possibly shorten names based on the maximum identifier length per Dialect[1]. PhysicalNamingStrategy is the most natural place to put this. However, that means when a user supplies a Phy

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

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

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

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

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

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

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

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 wou

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

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

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

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 h

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

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

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

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 determineJo

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

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 Ident

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

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

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

Something like: public interface ImplicitNamingStrategy { public Identifier determinePrimaryTableName(ImplicitEntityNameSource source); public Identifier determineJoinTableName(ImplicitJoinTableNameSource source); public Identifier determineCollectionTableName(ImplicitCollectionTableNameS

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

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

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

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 c

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

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

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

See inline... On Tue, Jan 13, 2015 at 3:30 PM, Sanne Grinovero wrote: > Funny I just praised the "NamingStrategy" in the OGM thread. So I > agree people badly want to specify their own "physical" naming > strategy but I don't see any value into making the logical > representation pluggable. > It

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

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 consiste

[hibernate-dev] Naming and "naming strategies"

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