1

I have JavaScript program containing two transactions:

T1 -> generate new documents within the database (update statement)

T2 -> transform existing MarkLogic documents

The successful execution of this program requires both transactions either succeed or rollback.

I wish to control the execution such that I can see the in-memory new documents but later rollback after T1 testing. If I am fully satisfied with T1, proceed T2.

In RDBMS (Oracle), I have the leverage to manipulate, view and rollback such changes (akin to taking a snapshot, when action is completed, snapshot is discarded).

How can I gain such control in MarkLogic?

Fiona Chen
  • 1,358
  • 5
  • 16
  • https://stackoverflow.com/a/53285498/14419 – Mads Hansen May 25 '20 at 03:00
  • xdmp.eval doesn't work in below case: ```declareUpdate(); const sem = require("/MarkLogic/semantics.xqy"); sem.rdfInsert([ sem.triple( sem.iri("http://example.org/band/The_Beatles"), sem.iri("http://example.org/band/origin"), sem.iri("http://example.org/band/United_Kingdom") ) ]);``` This is just a simple one-statement transaction. – Fiona Chen May 25 '20 at 13:23

1 Answers1

0

The insertion occurs at the end of the current statement, so to see the results, it would be necessary to start a multistatement transaction, insert in one statement, read in the next statement, and commit or rollback.

That said, in MarkLogic, the better and common approach is to verify the inputs before inserting so the transaction can happen in a single statement. if the inputs are valid and available to the main module, there's rarely any reason to reread the input from the persisted data.

For instance, with triples, it would be typical to use sem.rdfParse() and validate the triples before executing sem.rdfInsert(). Or, if using TDE to project the triples, to execute tde.nodeDataExtract() before a xdmp.documentInsert().

Hoping that helps,

ehennum
  • 7,295
  • 13
  • 9
  • Many thanks! It is difficult to control JavaScript transactions if ```xdmp.eval/invokeFunction``` can’t rein in the transaction mode. Let’s dumb down to just T1 which is to query then insert new documents. The logic of the query is to search documents on ONE property (e.g name) of which the value has duplicates (e.g 70 duplicate name), iterate such documents, retrieve required values ( e.g 70 topics/per name) , then create one Triple consists of 70 topics. This is combination of query and update transaction. – Fiona Chen May 26 '20 at 20:59
  • The result was insertion of 70 Triples on the same name. Even the instruction is to stop insertion if it is duplicated name…The desired result is one XML Triple on each distinct name. I manage to reduce the query result from 70 to 1, iterate and generate one Triple on each distinct name. It doesn’t seem to have that problem if the transaction is strictly QUERY mode . – Fiona Chen May 26 '20 at 20:59
  • From these additional comments, the issue doesn't sound like a rollback. If I understand the problem correctly, the best approach is to have the controlling logic first invoke the query logic in an isolated transaction with update false and commit auto and then invoke the update logic in an isolated transaction with update true and commit auto. In other words, the controlling logic should be in a separate transaction from both the query and update logic with auto commit for all three. – ehennum May 27 '20 at 15:50
  • My understanding of JavaScript transaction is auto-commit by default. You can control the transaction type by those xdmp functions. The backdrop of the rollback is that ```xdmp.invoke/eval/invokeFunction``` is not applicable for RDF insert or SPARQL update. I gather semantics module import and RDF insertion complexity are the main hindrance. – Fiona Chen May 27 '20 at 16:41
  • If the query logic returns preexisting triples that would be duplicates, the controlling logic can filter out those triples out before handing the rest of the triples to the update logic. On the other point RDF allows for duplicate triples and SPARQL can filter out duplicates as part of the query. Deduplication is expensive, however, so it is better to filter out duplicates before insertion. – ehennum May 28 '20 at 00:37