> On 09 Jan 2015, at 19:57, Sanne Grinovero wrote:
>
> # JBoss Forge integration for Hibernate Search
> # CDI extensions
> # Taking advantage of efficient loading profiles (the JPA 2.1
> feature): auto-generate the ones Search needs
I quite like these three. Especially the first two.
__
In the forum came an interesting proposal for Hibernate OGM.
https://forum.hibernate.org/viewtopic.php?f=31&t=1037739&sid=9ee9d4772ac6dfaa67a37ec02b2c330c&p=2482498#p2482498
Today I think OGM works quite well for document store and even Neo4J because
they don’t have any schema and thus we can sto
> 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 no
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 lo
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
You'd need to not specify the JtaPlatform service stuff.
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
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 ha
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
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
