On 24 Jun 2014, at 15:07, Gunnar Morling wrote:
> 2014-06-24 14:55 GMT+02:00 Emmanuel Bernard :
>
> On 24 Jun 2014, at 11:50, Gunnar Morling wrote:
>
>> Yes, today we don't.
>>
>> But is there any reason for not using the value column name?
>
> Not more that the ones I outlined in this thre
Gunnar,
I think the reason it was a SessionFactoryServiceRegistry is because it depends
on the DatastoreProvider which itself needed to be called by our custom
OgmSessionFactoryServiceRegistry which calls StartStoppable (DatastoreProviders
can also implement StartStoppable.
Also, it seems your
I pushed a test case that simulates what can happen with remote EJB
invocations that share the same JTA transaction & EntityManager. The
"Transaction was rolled back in a different thread!" error [2] is thrown
but shouldn't be, since the active application thread has changed to a
different thr
Gunnar and I discussed this on IRC. In my opinion, the easiest solution is
to make GridDialect associated with the StandardServiceRegistry, not the
SessionFactoryServiceRegistry. Gunnar was going to see if this was
possible. This would actually align with how ORM does it where Dialect and
JDBC r
2014-06-24 14:55 GMT+02:00 Emmanuel Bernard :
>
> On 24 Jun 2014, at 11:50, Gunnar Morling wrote:
>
> Yes, today we don't.
>
> But is there any reason for not using the value column name?
>
>
> Not more that the ones I outlined in this thread.
>
> In fact that's what my pending PR
> https://githu
On 24 Jun 2014, at 11:50, Gunnar Morling wrote:
> Yes, today we don't.
>
> But is there any reason for not using the value column name?
Not more that the ones I outlined in this thread.
> In fact that's what my pending PR
> https://github.com/hibernate/hibernate-ogm/pull/337 does for MongoDB
Yes, today we don't.
But is there any reason for not using the value column name? In fact that's
what my pending PR https://github.com/hibernate/hibernate-ogm/pull/337 does
for MongoDB. Right now it even allows to work with different value column
names for the same table (either in the same or in
I don't have a completely satisfying answer to this question, but an ad-hoc
solution which may work well enough.
The idea is to use SigTest [1] to create a file which contains all the
signatures of your public API; This file contains information about method
parameter and return types but also inh
