HSEARCH-3671 Make SearchScope session-independent

[yrodiere]

https://hibernate.atlassian.net/browse/HSEARCH-3671

[gsmet]

Is this mandatory? I must admit I'm not excited by the fact that we have to passe the EMF and the EM. It makes things far less fluid IMHO.

[yrodiere]

Eventually, people who don't want to load entities will be allowed to call scope.search() (if using single-tenancy) or scope.search(tenantId) (if using multi-tenancy). That's not implemented yet.

For people who actually want to load entities, well, we need an entity manager. Yes, we have a factory, but I don't think creating the entity manager ourselves silently would be a good idea. The loaded entities would not be usable anyway.

I could provide a way to pass the scope to a SearchSession, e.g. searchSession.search( scope ), but then you need an entity manager to create the SearchSession, so it's just more verbose.

Also, please keep in mind this is just the syntax with scopes, which is not really the one I want to promote. Let's say it's an alternate, lower-level syntax. The first syntax, with a SearchSession, is much better in most cases.

[yrodiere]

If the only problem you have is with the example itself, and the appearance of code for users who just don't want lambdas, I suppose I could also restore the scope() methods on the session. Then users will be able to trigger the search and create scope from a single object that was created from an entity manager.

However, the scopes will still be session-independent, so the search() method on those will still take an EntityManager in parameter. This method generally won't be useful though, since people can just call search on the session.

[yrodiere]

I just pushed a few other commits to not require passing an entity manager when creating a SearchWriter or a MassIndexer. I'm beginning to think that, maybe, for those two cases, we should promote the mapping + scope syntax rather than the session syntax. I.e.:

MassIndexer indexer = Search.mapping( entityManagerFactory ).scope( MyEntity.class ).massIndexer();

Rather than:

// This entity manager is created for the only purpose of calling our API. It's not really useful.
EntityManager entityManager = entityManagerFactory.createEntityManager();
MassIndexer indexer = Search.session( entityManager ).massIndexer( MyEntity.class );

... but I suppose it's too verbose? :)

[fax4ever]

Making the scope session-independent has a lot of advantages it term of decoupling. I agree with you the scope should not be related to a session instance.

On the other hand, my concern I think is the same that @gsmet has: make the API less easy to use.

I think that a Hibernate user expects to work on a session instance. IMHO creating a scope from a mapping derived from a session factory, then apply a session instance to it could be seen from him too much complicated.

I know that the user can bypass the scope extraction and, in that case, the API to search is the same, but I have some concern about to give him an API that has too many steps, even if there is an alternative.

[yrodiere]

I reverted some of the changes to keep the previous syntax searchSession.scope( ... ) and introduce a new searchSession.search( scope ) method.

So the syntax with object (which, keep that in mind, is an alternative syntax) will be:

SearchSession searchSession = Search.session( entityManager );
SearchScope<Book> scope = searchSession.scope( Book.class );
return searchSession.search( scope )
    .predicate( scope.predicate().matchAll().toPredicate() )
    .fetchHits( 20 );

... with the possibility to create the scope from the mapping directly, if need be (no example in the documentation yet, I'll introduce some when it's actually useful).

It is, I think, fairly similar to what we used to have:

SearchSession searchSession = Search.session( entityManager );
SearchScope<Book> scope = searchSession.scope( Book.class );
return scope.search()
    .predicate( scope.predicate().matchAll().toPredicate() )
    .fetchHits( 20 );

[yrodiere]

@fax4ever Actually never mind, I think you already have enough review work. I addressed your comments with the last few commits, so I'll merge once the CI build succeeds.

[fax4ever]

Anyway @yrodiere. seeing the API, not handling a full review of the changes, I can say we have reached a good compromise.

[yrodiere]

Thanks @gsmet and @fax4ever ! Merged.