Hello,
I am trying to do updates within the if-then-else statement. I’ve got a xquery parsing error.
for $q in input()/user
where $q/lastname = 'xxx' and $q/firstname = 'yyy'
return if (count($q)>0)
then(update replace $q/phonenumber with 'zzz')
else(update insert <user><lastname>xxx</lastname><firstname>yyy</firstname><phonenumber>zzz<phonenumber></user>)
I assume that update is not supported in if-then-else statement.
My scenario is that: if the user exists, I just change the phonenumber, if not, I have to insert the user completely.
I am searching for a way to solve this problem with one xquery instead of two.
Hi mz
There is no “docusment constructor” supported in Tamino 441
It is my impression that it is on the roadmap for the next major release scheduled later this year.
Hi finn,
thanks a lot!
Since the document construct is not supported, I have to use the API to insert a new document.
In my case two XQuerys are required: the first one tests the presence of the document and the second one insert a new doc with API or update insert a new element in the existent document.
As far as the concurrency access concerned, is isolationlevel committedcommand fit for this case?
Hi mz
Yes - use the API or make a “server extension function” (stored procedure) that stores a document.
This server extension function can be used directly inside the XQUERY.
Personally I think this would be the more elegant - but perhaps not easiest - solution
Finn
PS I must admit I’m not a locking expert
Perhaps someone else can answer that part of the question ?
Hi mz,
if you have a key constraint on lastname and firstname then this ensures that there can be always only one document with xxx and yyy, independent of the isolationlevel.
If there is no such key constraint, then you need to have isolationlevel serializable to ensure uniqueness. Otherwise two concurrent transactions might not find a document with xxx and yyy and since there is no such document they cannot lock it. Afterwards, both transactions can insert a new document. With isolationlevel serializable you should use lockmode protected, otherwise you might run into deadlocks. Please note, this combination of isolationlevel and lockmode excludes most concurrent transactions, therefore I would prefer the key constraint.
As far as I can see, the server extension based solution will probably not solve the deadlock issue (first just reading in the query part and then updating in the server extension part) but may be I missed something.
