<sannegrinovero> emmanuel, with DavideD we where looking at how to let OGM plug in a different indexing strategy.
<sannegrinovero> the initial thought was to use the ServiceRegistry in Search to load a custom one, and have this configured by a configuration property.
<sannegrinovero> So OGM could set the property and provide the alternative implementation based on the GridDialect capabilities
<sannegrinovero> but ..
<sannegrinovero> the ServiceRegistry in Search is bound to the lifecycle (can be used only during the initialization context), and this is specific to the code of hibernate-search-engine
<sannegrinovero> which doesn't know about the MassIndexer as that's ORM specific.
<sannegrinovero> So we're going to use the Hibernate ORM ServiceRegistry, looks good to you?
<emmanuel> sannegrinovero: yes I think the ORM SR is the way to go for OGM
<emmanuel> We are deep into ORM territory anyways
<emmanuel> but I'm not sure what you mean by different indexing strategy
<emmanuel> is that to customize Hibernate Search?
<sannegrinovero> yes to override the implementation it's going to create when creating a MassIndexer
<sannegrinovero> fullTextSession#createIndexer
<emmanuel> isn't SearchConfiguration the proper integraiton point?
<sannegrinovero> mm OGM doesn't override that one
<sannegrinovero> that used to be the integration point for Infinispan Query
<sannegrinovero> I'd expect OGM to set a simple property defining the FQCN of an alternative MassIndexerFactory
<sannegrinovero> so to keep it transparent to the user
<emmanuel> let me look
<emmanuel> sannegrinovero: I might be wrong but I think Searchconfiguration should expose this factory contract
<sannegrinovero> emmanuel, so OGM is going to implement a custom SearchConfiguration ?
<emmanuel> SearchConfigurationFromHibernateCore can then use a hibernate.search. config proeprty to resolve that
<emmanuel> no
<emmanuel> I imagine the MAssIndexer for ISPN is different than for regular ORM than for OGM
<emmanuel> but for a regular ORM usage or a regular Infinispan usage do you want to have diff implementations?
<sannegrinovero> they have already
<sannegrinovero> but for Infinispan it's different as it has its own API and so its own factory for batch-reindeing.
<sannegrinovero> there is no FullTextSession there
<emmanuel> I see
<emmanuel> you could have reuse MAssIndexer's API but it might be riddled with SQL specific stuff
<emmanuel> ok, then a regular factory is fine I suppose
<sannegrinovero> emmanuel, you can't use SearchConfiguration interface either as it's in the hibernate-search-engine module .. no dependencies to MassIndexer in the ORM module allowed.
<emmanuel> ok
<sannegrinovero> So our candidate is HibernateSearchIntegrator, to read the property naming a FQCN, instantiate it, and register it in the ORM registry.
<emmanuel> Hum
<sannegrinovero> the FTSession will just have to take it from the registry and invoke the factory method.
<emmanuel> but that's a Search object
<emmanuel> Why don't you keep at the SearchFactory level
<sannegrinovero> because it can't depend on ORM either
<sannegrinovero> this was my same train of thoughts
<sannegrinovero> ended up thinking we need a common repository for all those services needed by hibernate-search-ORM which can't have appropriate fields in SearchFactory
<sannegrinovero> and thought - since we're clearly in ORM world - to use the existing registry.
<sannegrinovero> (the ORM existing registry)
<emmanuel> ah I sort of get it
<emmanuel> no I don't
<emmanuel> "
<emmanuel> because it can't depend on ORM either
<emmanuel> "
<emmanuel> WDYM?
<sannegrinovero> SearchFactory can't depend on types in the package hibernate-search-orm
<sannegrinovero> If you really want we could move the MassIndexer interface into the hibernate-search-engine module but that looks fishy imho
<emmanuel> sannegrinovero: ok so your reasoning is that a service specific to search-orm can happily live in the ORM registry
<emmanuel> I guess that makes sense
<sannegrinovero> yes I hope so
<emmanuel> it goes a step away from a Hibernate independent orm module but that's nto a strong goal
<sannegrinovero> looks like a good home, even for more services to come, if any.