Loading ...
Sorry, an error occurred while loading the content.

Re: Newbie: some questions

Expand Messages
  • e9725082
    see below ... implement ... in an ... XML ... Yes thats right ... parameters. ... the ... which ... or ... correct ... just ... to ... The problem with finding
    Message 1 of 6 , Nov 20, 2003
    • 0 Attachment
      see below

      --- In xml-dbms@yahoogroups.com, Ronald Bourret <rpbourret@r...>
      wrote:
      > Sorry about the long delay in answering. I've been very busy.
      >
      > Comments below.
      >
      > e9725082 wrote:
      > > I want to transfer an XML document to the follwing structure
      > > "{ call procname( ?, ? )}".
      > > Its the same as for a PreparedStatement, I just use the
      > > CallableStatement object - everything is (almost) the same.
      > > I have a kind of "hack" for this problem. I "just" had to
      implement
      > > my own datahandler - and it works. In the implementation I just
      > > implemented the insert and selection part of the interface (delete
      > > makes in this context no sense). I could here reuse a lot of the
      > > existing code (some are just copy paste of the your original
      > > implementation).
      >
      > Just so I understand. What you are doing is passing values stored
      in an
      > XML document to a stored procedure. For example, you might use the
      XML
      > document:
      >
      > <Name>
      > <First>Ronald</First>
      > <Last>Bourret</Last>
      > </Name>
      >
      > to pass the first and last names to a stored procedure that looks
      like:
      >
      > addNewPerson(firstname, lastname)
      >
      > Is this correct?
      Yes thats right

      >
      > > The only problem what I face now is that the order of the
      parameters.
      > > For the selection part there should be a solution because I have
      the
      > > fixed order. I have not tried it yet but I hope I can do it.
      > > The bigger problem what I have is the insert because here I don't
      > > have the orderinfo object - The columns come from a hashtable -
      which
      > > means
      > > Hashtable.elements -> therefore they are ordered after the java
      > > hashtable alg. which can be very tricky when you have to call a
      > > stored procedure with 20 parameters.
      > > Here I have only 2 possibilties - either I change the order of the
      > > parameters of the stored procedure (which is mostly not possible)
      or
      > > I change the names of the XML document so that the order is
      correct
      > > (not really easy).
      > > I can just suggest that the interface of the datahandler for
      > > insert/update can be so extended that there is also the orderinfo
      > > object avaiable - would be nice:)).
      >
      > Two comments:
      >
      > 1) Changing the names in the XML document isn't that hard. You can
      just
      > use XSLT to perform a transformation. (Of course, this requires you
      to
      > know the Java hashing algorithm, which may be hard to find out.)

      The problem with finding out the hash alg. is very hard. Because it
      seems that
      its depends on the number of parameters and if the name is upper and
      lower case.
      The bigger problem is that not an XML element/attribute name is
      stored in the
      hashtable but a column object!! Sofar I can only find the order by
      stepping through the code.
      Which makes it basically unusable for other users.

      >
      > 2) I looked at the latest version of the code, which is currently
      only
      > on my machine. (I've modified a lot of the code surrounding data
      > handlers.) It's been a while since I had time to work on this and I
      > didn't look too closely, but it appears that the data will be
      passed to
      > DataHandler.insert in the order it occurs in the XML document. This
      > should solve the problem nicely. (As usual, no guarantees about when
      > this code will be available :(

      Is there maybe some download possiblity of the new code (without
      putting it to the cvs)??.
      So that I could try it if it would work with my solution?? Would be
      very nice :>>>

      >
      > > The advantage of this approach is that the dtd havenot to be
      changed.
      > > The procedure name is the tablename.
      > >
      > > As far as i understand the framework (I'm just guessing now) it
      would
      > > not be possible to call stored functions, e.g.
      > > {?= call proc(?,?,?)}
      > > because for generating the result document you need a result set
      with
      > > columnname(s) - the names are necessary to generate the XML
      document.
      > > I haven't tried it now and I know too few about stored functions
      to
      > > say know if I'm right or wrong with my assumption that it will not
      > > work with the current XML-DMBS implementation. But thats just
      > > theorectical for me now. Maybe you have here more experience.
      >
      > In this case, I assume you want to use the result of the function as
      > data to be returned in an XML document?

      Yes, exactly.

      >If so, you are correct that the
      > result must be returned (by the DataHandler.select method) as a
      result
      > set. Note that you could probably construct this result set
      yourself in
      > your DataHandler implementation. I took a quick look at the code
      and it
      > appears that the only methods in the ResultSet interface that you
      need
      > to implement are next(), close(), wasNull(), and getObject(int).

      Thx. I will try to implement my own interface, because sofar it seems
      that the
      data are still somehow mixed. I get always a conversion error when I
      have mixed
      parameterstypes (as strings, integer) but i do not know why, because
      in the
      result set everything is correct.

      >
      > > > And in anticipation of your next question, I refuse to say when
      I
      > > > will release the fix -- my schedule is just to hectic to make
      those
      > > > sorts of predictions :)
      > > I know that you are a very busy man and I also want to thank you
      for
      > > your great project - you saved my a lot of time. My only concern
      > > is/was that as long it is in the alpha state that changes in the
      DTD
      > > can be made which are not backward compatible. It would be just
      hard
      > > to explain user how to change their dtds (how,why,...).
      >
      > I wouldn't worry too much about DTD changes. The DTDs (especially
      > xmldbms2.dtd) are pretty stable. The next release has some minor
      changes
      > to Update and UpdateOrInsert in actions.dtd. I would love a nicer
      syntax
      > for filters.dtd, but haven't been able to think of one.

      thx for the info.

      >
      > -- Ron
    • Ronald Bourret
      ... If you want, I can email it to you privately, but: 1) You can t use the Transfer tool as that still needs to be updated. 2) The rest of the code has been
      Message 2 of 6 , Nov 20, 2003
      • 0 Attachment
        e9725082 wrote:
        > Is there maybe some download possiblity of the new code (without
        > putting it to the cvs)??.
        > So that I could try it if it would work with my solution?? Would be
        > very nice :>>>

        If you want, I can email it to you privately, but:

        1) You can't use the Transfer tool as that still needs to be updated.

        2) The rest of the code has been compiled but never run, so it almost
        certainly has bugs.

        > >If so, you are correct that the
        > > result must be returned (by the DataHandler.select method) as a
        > result
        > > set. Note that you could probably construct this result set
        > yourself in
        > > your DataHandler implementation. I took a quick look at the code
        > and it
        > > appears that the only methods in the ResultSet interface that you
        > need
        > > to implement are next(), close(), wasNull(), and getObject(int).
        >
        > Thx. I will try to implement my own interface, because sofar it seems
        > that the
        > data are still somehow mixed. I get always a conversion error when I
        > have mixed
        > parameterstypes (as strings, integer) but i do not know why, because
        > in the
        > result set everything is correct.

        Can you explain this more? I don't understand.

        -- Ron
      Your message has been successfully submitted and would be delivered to recipients shortly.