[hibernate-dev] Configuration and custom IdentifierGeneratorFactory implementations
Steve Ebersole
steve at hibernate.org
Tue Jun 24 13:01:36 EDT 2014
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 related services are part of the StandardServiceRegistry.
What would that gain you? Keep in mind that the IdentifierGeneratorFactory
is also a service that is kept in the StandardServiceRegistry. So by
making GridDialect part of the same registry, your custom
IdentifierGeneratorFactory
impl would have access to the GridDialect as it is building its generators (
OgmTableGenerator/OgmSequenceGenerator).
On Fri, Jun 20, 2014 at 7:46 AM, Gunnar Morling <gunnar at hibernate.org>
wrote:
> 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
> Configuration, from where it is accessed in the SessionFactoryImpl
> constructor. In my particular case the instantiation of Configuration is
> not under my control, so I can't sneak in a custom factory via a sub-class.
> Interestingly, (Mutable)IdentifierGeneratorFactory is also a service
> contract and as such is accessed via the service registry in other places.
>
> My understanding is that Configuration is supposed to go away in ORM 5
> anyways, so I'm wondering whether there is a low-effort solution to my
> problem as of 4.3.x.
>
> Would it be feasible to add Configuration#setIdentifierGeneratorFactory()
> for that purpose? This should help my case; It would require though that
> Configuration#mapping is calculated lazily since atm. it captures a
> reference to the initially set generator factory.
>
> Any thoughts?
>
> Thanks,
>
> --Gunnar
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
More information about the hibernate-dev
mailing list