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

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 reasona

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

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 actuall

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

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

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

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

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

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,

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

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

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

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

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"

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"

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

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"

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

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

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

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"

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