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(a)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