This content has been marked as final. Show 9 replies
You will need to create Java Functions for ODSI (again, in the documentation) to do the actual modifications. When you Create New Physical DataService for the Java Functions, check them as "update".
Ok then Mike, I hoped ODSI would have some way to automatically create the update procedures, but I'm seeing I'll have to do all the dirty work by myself. Any idea why ODSI doesn't implement such procedures? I mean, it would be trivial to create them for XML-based physical services.
Anyway, thanks for the clarification.
it would be trivial to create them
I'll have to do all the dirty work by myselfWait, didn't you just say it would be trivial? :)
There are several challenges with updating xml files - when you write your own updateXmlFile - it only needs to work for your case. If this were part of the product, it would need to handle every possible case. Here are some reasons :
xml files don't have keys, so it's impossible to know what changing
means. What if there are several such elements in the file?
2) Suppose your xml source is http://somewhere.com/myfile.xml - how are you going to update that? You can't.
3) Suppose your xml source is file:///myfile.xml - which is 6GB, how are you going to change the spelling of Jon to John? You're going to have to read and write 6GB.
4) how do you prevent a client from filling up your disk?
5) suppose your xml file is within your dataspace - what happens when an xml file is updated? What happens when your dataspace is redeployed? Are the updates lost?
6) Databases were invented to handle random access updates. So why not use a database?
7) Ah - here we go ...
Bug 7910366: [CR100991]
SHOULD PROVIDE APIS TO ALLOW USER TO UPDATE XML DATA FILE
Status 97 - Suggestion Rejected
Well, just because it's trivial it doesn't mean it's not a lot of work ;)
I do see some of your points, but they seem to be manageable to me. Let's see:
1) What's the problem in changing the <name> element? Like you said yourself, XML is not relational. It's not like the element would ever be a foreign key somewhere else.
2) True, you can't, so ODSI could block update procedures when related to external files.
3,4) If I really need to update my XML files and create custom functions to do so, as per your prior suggestion, I would still have such problems. So if the situation presents itself it's just a drawback we'd have to live with, I guess.
5) I don't see how the updates would be lost. I'm assuming all change to the data would be persisted on disk. So, if we redeploy our dataspace, the new data would be carried along.
6) Well, it's not always under our control how the data is being stored, is it? I think this is one of the reasons in using ODSI in the first place.
All in all, I do agree that in most cases it's probably not a good idea to have update procedures related to XML and csv files, but still there are situations in which they can be useful, and ODSI could provide that usability.
1) What's the problem in changing the <name> element? Like you said yourself, XML is not relational. It's not like the element would ever be a foreign key somewhere else.I guess I didn't explain very well. Suppose your xml file has 1000 CUSTOMERS, of which 4 have identical names <NAME>SMITH</NAME>. Suppose a client retrieves one of those 4 customers, subtracts $100 from the account balance, and then calls update. What is ODSI supposed to do? Subtract 100 from all 4 SMITHs? Three of the SMITHs won't be happy about that. There is no "primary" key. I'm sure we could invent a mechanism to designate a primary key, and I'm sure I can point out problems with it. For instance, what if user designates the CUSTOMER_ID as a primary key - but it isn't unique? Again, you'll have some unhappy customers. Then again, ODSI would have to read the whole file anyway - to write it back out, it could verify that the key was unique - but it would have to parse the whole file instead of just up to the point where the updated element was.
3,4) If I really need to update my XML files and create custom functions to do so, as per your prior suggestion, I would still have such problems.Right. And you'd have to deal with them. I wouldn't :) If you're going to implement the same thing without ODSI - you'll still have to write functions to do so.
5) I don't see how the updates would be lost. I'm assuming all change to the data would be persisted on disk.If you wanted them saved, you'd need to (manually) export them from the dataspace via the odsiconsole, and then import them into your dataspace in studio. Otherwise, the next time some developer redeployed the dataspace, it would over-write the xml file with the original. Then you'd need a mechanism to determine if the xml files of record were the once from the deployment or the ones in the dataspace.
So there are number of problems - with uniqueness, performance, persistence, locking, transactions, security - all of which have been solved by databases.