9 Replies Latest reply: Aug 2, 2011 4:36 PM by mikereiche RSS

    Updating Physical Services other than relational ones

    pedro.dantas
      Hi guys,

      I have a doubt: is it only possible to update Physical Services based on relational databases? Is there any way to create an update/delete procedure from a XML or csv based service? I'm using ODSI 10gR3.

      Thanks in advance,

      Pedro Ivo
        • 1. Re: Updating Physical Services other than relational ones
          mikereiche
          is it only possible to update Physical Services based on relational databases?
          If you want to update anything else, you need to write your own "update/delete" procedures.

          - Mike
          • 2. Re: Updating Physical Services other than relational ones
            pedro.dantas
            Mike,

            Thanks for your reply. Could you give me an example of such procedures?

            Pedro Ivo
            • 3. Re: Updating Physical Services other than relational ones
              mikereiche
              Please refer to the product documentation

              you can search it with google like this :

              http://www.google.com/search?q=update+physical++site%3Ahttp%3A%2F%2Fdownload.oracle.com%2Fdocs%2Fcd%2FE13162_01%2Fodsi%2Fdocs10gr3+odsi
              • 4. Re: Updating Physical Services other than relational ones
                pedro.dantas
                Mike, I had already checked the documentation, bout could not (and still can't) find any suitable example.
                • 5. Re: Updating Physical Services other than relational ones
                  mikereiche
                  http://download.oracle.com/docs/cd/E13162_01/odsi/docs10gr3/dsp32wiki/How%20To%20Develop%20Good%20XQSEs.html#HowToDevelopGoodXQSEs-ReplicatedEmployee.ds%3AHowtoMakeXQSEsforUpdates

                  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".
                  • 6. Re: Updating Physical Services other than relational ones
                    pedro.dantas
                    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.
                    • 7. Re: Updating Physical Services other than relational ones
                      mikereiche
                      it would be trivial to create them
                      I'll have to do all the dirty work by myself
                      Wait, 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 :


                      1)

                      xml files don't have keys, so it's impossible to know what changing

                      <CUSTOMER><NAME>Smith</NAME></CUSTOMER>

                      to

                      <CUSTOMER><NAME>Smythe</NAME></CUSTOMER>

                      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
                           
                      Created 12-Mar-2003
                           
                      Status 97 - Suggestion Rejected
                      • 8. Re: Updating Physical Services other than relational ones
                        pedro.dantas
                        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.
                        • 9. Re: Updating Physical Services other than relational ones
                          mikereiche
                          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.