Hi Christoph,
I’m forwarding my answer (including yours) to the mailing list, as I think it is valuable input.
I totally agree that the ‘equivalency' XQuery/transaction is very limiting. It sometimes leads to weird constructs trying to bypass the limitation.
Quite often though the limitation is actually useful, as it forces you to re-write your query in a way that it fits a single transaction. Within a single transaction the compiler then has a lot more room for optimization etc.. I’m not defending our current approach here - there are cases where it causes real pain and affects overall application design. But I also think that, more often then not, a functional programming approach also solves the issue including all the benefits. After all, the concept of the XQuery Update Facility is true to the functional nature of XQuery, where variables are final (and cannot be changed once initiated). Extending XQuery with db:commit() kind of breaks these basic principles. I also think support for ‘chaining transactions’ would be beneficial, but maybe on another level (commands?).
We write loads of production code in XQuery and this reflects just our experience - but I’d be happy to hear what others have to say.
Cheers,
Lukas
> On 09 Feb 2015, at 09:38, Christoph Gaukel <christoph.gaukel(a)gmx.de> wrote:
>
> Hi Lukas,
>
> thank you for your answer, but this is no good news. In my specific case, i see a variant to solve the problem. But i think, that the concept of transactions, which combines a number of updating commands into an atomic unit, is a good idea and it is a heavy load on the freedom of design if the only chance, to build transactions is the unit of an xquery.
>
> From my point of view, it would be an important improvement, if something like the commit of sql would be added to the xquery-language. If BaseX would introduce it as a specific extension like db:commit(), this would be great!
>
> Cheers,
> Christoph