Ok, so we may want to add a little xdmp:sleep() after the document insert instruction I guess. Thanks for your help.
cheers, Jakob. On Tue, May 6, 2014 at 5:53 PM, John Snelson <[email protected]>wrote: > Triple index updates are transactional, so you can see them as soon as > the inserting transaction has completed. I suspect you're seeing a race > conditions with the inserting transaction. > > John > > On 06/05/14 16:22, Jakob Fix wrote: > > John, > > > > Maybe a misunderstanding in my message: We're inserting the XML document > > which triggers the pre-commit trigger that generates the triple document > > in a *separate transaction from the test itself*, in order to be able to > > query it. For this to work, we're inserting the document via an HTTP > > POST request of our API, a call that is blocking, so we expect the > > document to be query-able (which is the case), and a SPARQL query to > > return the inserted triples (which is not always the case). > > > > > > cheers, > > Jakob. > > > > > > On Tue, May 6, 2014 at 4:21 PM, John Snelson <[email protected] > > <mailto:[email protected]>> wrote: > > > > On 06/05/14 15:17, Jakob Fix wrote: > > > we are doing xray unit testing for our application, and one of the > > > issues we run into occasionally is that even though we know that > > triples > > > have been created and stored as triple documents, they are not > always > > > (but sometimes) found when executing a sparql query in the same > > test. by > > > the way, triples are created by extracting information from an XML > > > document, via a pre-commit trigger before storing the XML document > > > proper. oh yes, and the document is inserted in a separate > > transaction. > > > > > > could this be due to the fact that these documents are not indexed > > > immediately, but periodically? > > > > No, it's because you insert the document containing triples in a > > separate transaction. Why don't you insert it in the same > transaction if > > you're using pre-commit triggers? > > > > John > > > > -- > > John Snelson, Lead Engineer http://twitter.com/jpcs > > MarkLogic Corporation http://www.marklogic.com > > _______________________________________________ > > General mailing list > > [email protected] <mailto: > [email protected]> > > http://developer.marklogic.com/mailman/listinfo/general > > > > > > > > > > _______________________________________________ > > General mailing list > > [email protected] > > http://developer.marklogic.com/mailman/listinfo/general > > > > > -- > John Snelson, Lead Engineer http://twitter.com/jpcs > MarkLogic Corporation http://www.marklogic.com > _______________________________________________ > General mailing list > [email protected] > http://developer.marklogic.com/mailman/listinfo/general >
_______________________________________________ General mailing list [email protected] http://developer.marklogic.com/mailman/listinfo/general
