Re: [hibernate-dev] Configuration and custom IdentifierGeneratorFactory implementations

2014-06-25 Thread Gunnar Morling
2014-06-25 8:51 GMT+02:00 Emmanuel Bernard : > 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 c

Re: [hibernate-dev] Configuration and custom IdentifierGeneratorFactory implementations

2014-06-24 Thread Emmanuel Bernard
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

Re: [hibernate-dev] Configuration and custom IdentifierGeneratorFactory implementations

2014-06-24 Thread Steve Ebersole
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

[hibernate-dev] Configuration and custom IdentifierGeneratorFactory implementations

2014-06-20 Thread Gunnar Morling
Steve, all, I would like to work with a custom IdentifierGeneratorFactory which performs a specific configuration of created generators (basically I want to pass OGM's GridDialect instead of the original Dialect contract). Now the problem is that DefaultIdentifierGeneratorFactory is hard-wired in