[hibernate-dev] Configuration and custom IdentifierGeneratorFactory implementations

[Gunnar Morling]

2014-06-25 8:51 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:

> 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 new GridDialect Initiator uses EventListenerRegistry
> which is SessionFactoryServiceRegistry specific.
>
> If you dodge these two, we can make GridDialect a StandardServiceRegistry
> citizen.
>

Yes, this may be doable. There also is OptionsService which would need to
be moved to the standard registry as well, since it is referenced by
DatastoreProvider implementations.

But the bigger issue is that IdentifierGeneratorFactory unfortunately is
not always consumed via the service registry, but it's retrieved directly
from Configuration where the ORM default implementation is hard-wired. So I
can't replace it with our custom OGM IdentifierGeneratorFactory
implementation.

Still moving GridDialect to the standard registry would help, as it allowed
to expose the GridDialect via the OGM Dialect implementation (NoopDialect,
maybe then to be renamed into OgmDialect). This would make it accessible
from identity generators during the configuration phase (which get the
Dialect passed).

It feels a tiny bit hacky, but it seems acceptable to me for the time
being. Having done all these changes, the test suite still passes for me.
Once IdentifierGeneratorFactory is consistently consumed via the service
registry, we may remove the exposure of GridDialect via Dialect again, and
have it pass the GridDialect directly to created id generators.

--Gunnar


Emmanuel
>
> On 24 Jun 2014, at 19:01, Steve Ebersole <steve at hibernate.org> wrote:
>
> > 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
> >>
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>