I've done a deeper analysis, here is what I am thinking about query.SearchTimeoutException why is it not a subclass of SearchException?
query.SearchTimeoutException => query.engine.SearchTimeoutException (API) ? (I don't see why the persistence layer could not let this exception go as is). query.engine.internals => query.engine.impl (core uses internals but many packages in HSearch use impl already) query.engine.HSQuery => query.engine.spi.HSQuery (the engine is essentially a SPI) query.TimeoutManager => query.engine.spi.TimeoutManager //interface? query.engine.TimeoutExceptionFactory => query.engine.spi query.ScrollableResultsImpl => query.hibernate.impl query.QueryHits => query.engine.impl query.ObjectLookupMethod => query.hibernate or query.orm query.ObjectLoaderBuilder => query.hibernate.impl query.IteratorImpl => query.hibernate.impl query.FullTextQueryImpl => query.hibernate.impl query.FullTextFilterImpl => query.engine.impl query.DatabaseRetrievalMethod => query.hibernate or query.orm? query.impl => query.hibernate.impl Should there be a query.orm and query.hibernate? engine.EntityInfo => query.engine.spi engine. AbstractLoader => query.orm.impl / query.hibernate.impl engine. DocumentExtractor => query.engine.spi engine. Loader => query.orm.impl / query.hibernate.impl engine. LoaderHelper => query.orm.impl / query.hibernate.impl engine. MultiClassesQueryLoader => query.orm.impl / query.hibernate.impl engine. ObjectLoaderHelper => query.orm.impl / query.hibernate.impl engine. ProjectionLoader => query.orm.impl / query.hibernate.impl engine.QueryLoader => query.orm.impl / query.hibernate.impl I have also introduced a while back the notion of SearchFactoryIntegrator vs SearchFactoryImplementor. The former used by frameworks integrating with HSearch and the latter for internals using SearchFactory's contracts. Following the same vein, we might need to: - rename StatisticsImplementor to StatisticsIntegrator (framework seems to need to call back this service) - move SearchFactoryImplementor#getStatisticsImplementor() to SearchFactoryIntegrator#getStatisticsIntegrator() We might need to introduce a notion of DocumentBuilder SPI which is really the metadata API Hardy wants in or an extension of. I think the Integrator business can wait for 4.0 but until it's done, some of the query engine contracts are leaky in some area. For example the Loaders do need some of the SessionFactoryImplementor contracts. On 2 mars 2011, at 23:40, Sanne Grinovero wrote: > ok, you don't have conflicts with Hardy either: > https://github.com/hibernate/hibernate-search/pull/50/files > > 2011/3/2 Emmanuel Bernard <emman...@hibernate.org>: >> I am thinking about moving: >> EntityInfo >> AbstractLoader >> DocumentExtractor >> Loader >> LoaderHelper >> MultiClassesQueryLoader >> ObjectLoaderHelper >> ProjectionLoader >> QueryLoader >> >> >> On 2 mars 2011, at 23:19, Emmanuel Bernard wrote: >> >>> It seems that the engine package content is entirely related to query and >>> should move somewhere under o.h.search.query. >>> Any opinion or objection? Most are non API non SPI classes anyways. >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev@lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
