Hi there,
I have a very extensive document in the server repository and I would like to update or insert subnodes either using the Java API or a simple query (sort of what is done using SQL). Does anybody know how to do that in X-Query or any equivalent? I don’t want to create an instance of the entire tree just to insert a subnode…
Any ideas?
Thanks in advance,
– Juan
Technically, Tamino in current versions (2, 3) can not partially update a document (subtree update). With Tamino it is always Take Whole Document - Edit Whole Document - Write Whole Document Back.
But, with MS IIS there is a subtree update filter available. Please search the documentation on this subject. In short, it introduces some API-calls for subtree manipulation that are then performed in above manner on the server side.
So, the benefit is that you don’t have to handle the large instance on the client.
Best regards, Andreas
Thanks Andreas, you have been the only one that answers that question in all forums. It seems to me to be a real disadvantage of Tamino… what is then the difference of just writing the XML in a file? do you know if Tamino will manage multiple put-backs at the same time? if you have multiple connections requesting the same document that another connection is modifying, how does it manage that? what if the second connection is also trying to modify the document?
Thanks again,
– Juan
Hello Juan!
I got a problem just like yours. I have to update a very large document in Tamino I couldn
Yeah, this question has always been a headache for me too. Maybe no one dared answer it before, because it doesn’t have a simple solution.
Designing schemas is often a every difficult compromise.
If I want to utilize the advantage of XML to represent very complex structure, I can create “all-in-one” schema. Then it will be easy to publish documents, just to apply a stylesheet. But if I’d like to update a single node? I have to load a whole document in my program, change it and send back.
Another approach. I decide that updates must become easier. Then I have to normalize my schema (just like in relational model) into several schemas. But if my report spreads several doctypes? Tamino doesn’t like joins. I think very few projects utilized built-in predefined join capabilites (they are very limited). So it is again an invitation to code it manually.
Tamino is excelently suited to store electronic documents that are analogues to paper documents. And store them exactly as they come (for instance with no classifiers involved). Those documents are usually not very large. So you can perfectly manage them in Tamino (store, search, retrieve, publish). But it’s important that you work with whole documents. For example an application form. It can have a very difficult structure (dozens of tables in the third normal form). But it is printed on just two sheets.
In other cases you should think very carefully when choosing Tamino. BUT I hope that the next version will change everything. Because it will support W3C XQuery (with joins and node level updates).
Sorry for emotional words. But it’s a sore subject for me.
So about large documents. If they are so large that cannot be sent with one HTTP request, then you certainly have to decompose them. Especially if a document represents a list of repeating objects with same type. Unless it will take you long to update and retrieve them.
For concurrent access to the same documents in Tamino, see isolation levels in Documentation (“Requests using X-Machine Commands”).
[This message was edited by Alexander on 20 Nov 2002 at 20:57.]