[hibernate-dev] [OGM-8, OGM-21] initial "criteria query" search

[Sanne Grinovero]

Hi Cyrille,
thank you that's very interesting, I'll have a look into your code.
Some more comments inline:

2011/8/17 Cyrille Chépélov <cyrille at chepelov.org>:
> Hi Sanne,
>
> Le lundi 15 août 2011 à 16:48 +0100, Sanne Grinovero a écrit :
>
> Regarding queries, you can use it with Hibernate Search as we did in a
> demo at JBoss World [1], that doesn't provide all power of relational
> queries but can still deal with most needs (and full text queries as
> well); the only thing you have to consider is to use
>
> Well; the application for which I'm experimenting with OGM/Infinispan
> requires a synchronous search behaviour (which is, once a write transaction
> completes, subsequent 'read' transactions must show immediately the modified
> state). A previous implementation of the service currently struggles,
> because it attempts to expect this from SOLR (meep! wrong). Eventually
> relying on Lucene again won't buy me much here :)

Agreed that Lucene will introduce an overhead/slowdown during
insertions, but we're still able to provide both synchronous updates
and transactionality to some extent (currently failing to write to the
Lucene index won't rollback the transaction).
Also with Hibernate Search 4 coming quickly (1-2 months, an alpha very
soon) we're going to minimize write latency to the extreme, you won't
ever need to wait for merge operations, optimizations or disk flushes.

>
> As both OGM-21 (no JP-QL) and OGM-8 (no Criteria Queries either) block me,
> and before temporarily retreating on JPA(Hibernate)+Postgres, I've played
> with sketching a very early implementation of CQ support.  Not much, not
> properly tested, nothing, but enough to get a my single use case somewhat
> working:
>
> /* with
>
> @Entity
> public class Document {
>     @Id
>     @GeneratedValue(generator = "uuid") @GenericGenerator( name="uuid",
> strategy = "uuid2")
>     String internalUuid;
>
>     @NaturalId
>     private String docuid;
>
>     public String title;
> }
>
> */
>
>         CriteriaBuilder cb = em.getCriteriaBuilder();
>
>         CriteriaQuery<Document> cq = cb.createQuery(Document.class);
>         Root<Document> clRoot = cq.from(Document.class);
>
>         cq.select(clRoot).where(cb.equal(clRoot.get("docuid"), uid));
>
>         /* List<Document> docs = em.createQuery(cq).getResultsList(); */
>         List<Document> docs = TypedCriteriaQueryFactory
>                 .createTypedQuery(em, cq).getResultList();
>
> caveats:

that's awesome, I would love to see you adding tests and polishing
enough to be included in OGM.

>
> apparently, Infinispan's Distributed Execution Framework requires the
> clustering mode to be "distribution"; "replication" ought to be fine too,
> but the engine seems to have strong opinion against this.
> only the simplest queries have a chance to work
> a full scan on the whole ENTITIES cache is going to happen on every query.

Please open a feature request on Infinispan, I agree we need a
consistent API for both clustering modes,
and even LOCAL should be supported, at least to simplify testing. Also
please post here a reference, I'd be glad to vote and follow the
issue.

> And then an individual load(by @Id) on each matched entity.
> for the moment, this is implemented as external code, rather than a proper
> patch. Hence a fairly ugly "ClandestineAccess" class. I guess a more correct
> implementation will have to find a better way to bounce from
> OgmEntityManager down to the InfinispanDialect, but for now Session seems to
> have a fairly strong opinion that the query world is about JDBC and HQL->SQL
> translations only.
I know :( that should change soon anyway, even though our initial HQL
translation plans where towards using Lucene, we'll want to support
the Distributed Executor too, better even both.

> Apparently, sometimes the ghost of a previous instance is detected by
> Infinispan which then fails because of a remote invocation error. I guess
> this is more an issue with eclipse starting new sessions before killing the
> previous one.

Yes making sure an Infinispan CacheManager is completely killed is
tricky. Make sure you shutdown the SessionFactory, when using OGM, or
if starting instances directly for test purposes have a look into
TestUtils in Infinispan: there are some methods used to make sure a
CacheManager is dead dead dead.. always tricky to deal with these
highly available systems :)

>
> With that said, I can now proceed!
>
>     -- Cyrille

Sanne