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

Reply via email to