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

Re: [xml-dbms] Re: Retrieving Data from One of Many Tables using a Single Map File

Expand Messages
  • Ronald Bourret
    Yes. See the following methods in DBMSToDOM: public Document retrieveDocument(TransferInfo transferInfo, ResultSet rs, FilterSet filterSet, Hashtable params,
    Message 1 of 9 , Sep 1 7:46 AM
    • 0 Attachment
      Yes. See the following methods in DBMSToDOM:

      public Document retrieveDocument(TransferInfo transferInfo,
      ResultSet rs,
      FilterSet filterSet,
      Hashtable params,
      Node rootNode)

      public Document retrieveDocument(TransferInfo transferInfo,
      Hashtable resultSets,
      FilterSet filterSet,
      Hashtable params,
      Node rootNode)

      You specify the name of the table(s) used to map the result set(s) with
      ResultSetInfo element(s) in the filter document. See filters.dtd for
      more information.

      -- Ron

      dling61 wrote:
      >
      > I want to know that if the second feature suggested by Ron is in v2.o
      > or not. Basically, I want to do the same thing as Roy does.
      >
      > --- In xml-dbms@y..., Ronald Bourret <rpbourret@r...> wrote:
      > > This isn't currently possible, but does suggest an interesting and
      > > very-easy-to-implement new feature:
      > >
      > > 1) Change the signature of DBMSToDOM.retrieveDocument(ResultSet rs)
      > to
      > > retrieveDocument(ResultSet rs, String rsName)
      > >
      > > 2) Change the code in retrieveDocument to get the map for rsName
      > instead
      > > of "Result Set". (The code should use "Result Set" if rsName is
      > null.)
      > >
      > > This would allow you to use the same map with multiple result sets.
      > This
      > > would be reasonable in a situation where you had a number of related
      > > tables (as described in the map) and wanted to have a number of
      > > predefined queries that worked with these tables.
      > >
      > > I've added this to the bug database as a new feature request.
    • dling61
      One more question to follow up this. I have a small enterprise data model containing about ten tables. I also have different queries to select tables. Some of
      Message 2 of 9 , Sep 11 11:43 AM
      • 0 Attachment
        One more question to follow up this.

        I have a small enterprise data model containing about ten tables. I
        also have different queries to select tables. Some of them perform
        join operations.

        I want to have a single filter document to cover all the queries I
        have. But it seems like XML-DBMS to construct every result set based
        on each filter defined in filter document. If I just want to restieve
        data from the customer table, XML-DBMS still go through all the
        filters defined and process "select". Is that right?

        Do I have to put different filters into different filter files in my
        case? Plus, I do want to use retrieveDocumentBySQL in this case.


        Thanks


        Dongling

        --- In xml-dbms@y..., Ronald Bourret <rpbourret@r...> wrote:
        > Yes. See the following methods in DBMSToDOM:
        >
        > public Document retrieveDocument(TransferInfo transferInfo,
        > ResultSet rs,
        > FilterSet filterSet,
        > Hashtable params,
        > Node rootNode)
        >
        > public Document retrieveDocument(TransferInfo transferInfo,
        > Hashtable resultSets,
        > FilterSet filterSet,
        > Hashtable params,
        > Node rootNode)
        >
        > You specify the name of the table(s) used to map the result set(s)
        with
        > ResultSetInfo element(s) in the filter document. See filters.dtd for
        > more information.
        >
        > -- Ron
        >
        > dling61 wrote:
        > >
        > > I want to know that if the second feature suggested by Ron is in
        v2.o
        > > or not. Basically, I want to do the same thing as Roy does.
        > >
        > > --- In xml-dbms@y..., Ronald Bourret <rpbourret@r...> wrote:
        > > > This isn't currently possible, but does suggest an interesting
        and
        > > > very-easy-to-implement new feature:
        > > >
        > > > 1) Change the signature of DBMSToDOM.retrieveDocument(ResultSet
        rs)
        > > to
        > > > retrieveDocument(ResultSet rs, String rsName)
        > > >
        > > > 2) Change the code in retrieveDocument to get the map for rsName
        > > instead
        > > > of "Result Set". (The code should use "Result Set" if rsName is
        > > null.)
        > > >
        > > > This would allow you to use the same map with multiple result
        sets.
        > > This
        > > > would be reasonable in a situation where you had a number of
        related
        > > > tables (as described in the map) and wanted to have a number of
        > > > predefined queries that worked with these tables.
        > > >
        > > > I've added this to the bug database as a new feature request.
      • Ronald Bourret
        There are two things going on here. 1) The map file defines the structure (hierarchy) of the retrieved data. Each different hierarchy requires a different map
        Message 3 of 9 , Sep 11 4:26 PM
        • 0 Attachment
          There are two things going on here.

          1) The map file defines the structure (hierarchy) of the retrieved data.
          Each different hierarchy requires a different map file, although you can
          enter a given hierarchy at any point.

          For example, consider the sample sales data, which uses the following
          hierarchy:

          Orders
          / \
          Items Customers
          |
          Parts

          I can use the map file for this hierarchy to generate XML documents that
          match this hierarchy, plus the following hierarchies:

          Items Customers Parts
          |
          Parts

          Note that XML-DBMS allows you to specify the root you want, then follows
          the hierarchy to the leaves. In other words, I need a separate map file
          for the following hierarchy, since it omits the parts table:

          Orders
          / \
          Items Customers

          I also need different map files for other hierarchies, such as the
          following:

          Parts Customers etc.
          | |
          Items Orders
          |
          Items
          |
          Parts

          Furthermore, a map file can define multiple, separate hierarchies
          (disconnected graphs), although there is generally no reason to do this.

          2) The filter file defines three things:
          a) Any "wrapper" elements that wrap the returned data.
          b) The root table to use and the select criteria for that table.
          c) Any additional filters between tables.

          For example, if I want to retrieve data starting with order number 123
          and getting all items with a quantity greater than 10, Orders is my root
          table, order number 123 is my root select criteria, and quantity greater
          than 10 is my additional filter criteria on the items table.

          So, to answer your question, you need:

          1) Different map files for different hierarchies.
          2) Different filter files for different filter values.

          Note that which filters are used depends on which tables are defined in
          the hierarchy. For example, if I include a filter for the Foo table but
          there is no Foo table in the hierarchy, the Foo filter is never used.
          Similarly, if I include a filter for the Customers table but specify
          that the Items table is my root table, the Customers filter will be
          ignored since it is not on the branch of the hierarchy starting with
          Items.

          In summary, having different maps and filters is no different than
          having different SELECT statements in SQL. The only difference is that
          map and filter files are big and hard to read and SQL is short and easy
          to read.

          -- Ron

          dling61 wrote:
          >
          > One more question to follow up this.
          >
          > I have a small enterprise data model containing about ten tables. I
          > also have different queries to select tables. Some of them perform
          > join operations.
          >
          > I want to have a single filter document to cover all the queries I
          > have. But it seems like XML-DBMS to construct every result set based
          > on each filter defined in filter document. If I just want to restieve
          > data from the customer table, XML-DBMS still go through all the
          > filters defined and process "select". Is that right?
          >
          > Do I have to put different filters into different filter files in my
          > case? Plus, I do want to use retrieveDocumentBySQL in this case.
        • Dongling Ding
          Thanks for the comments. In my application a user interface accepts query requests from users. That means during the run time I have to figure out which map
          Message 4 of 9 , Sep 11 6:20 PM
          • 0 Attachment
            Thanks for the comments.

            In my application a user interface accepts query
            requests from users. That means during the run time I
            have to figure out which map and filter file can be
            applied for a query, and then pass those into
            retrieveDocument(). Also, I have to maintain many map
            and filter files. Is that reasonable?

            What about XQuery? Is that going to address the above
            issues? I hope it will.


            Thanks


            Dongling


            --- Ronald Bourret <rpbourret@...> wrote:
            > There are two things going on here.
            >
            > 1) The map file defines the structure (hierarchy) of
            > the retrieved data.
            > Each different hierarchy requires a different map
            > file, although you can
            > enter a given hierarchy at any point.
            >
            > For example, consider the sample sales data, which
            > uses the following
            > hierarchy:
            >
            > Orders
            > / \
            > Items Customers
            > |
            > Parts
            >
            > I can use the map file for this hierarchy to
            > generate XML documents that
            > match this hierarchy, plus the following
            > hierarchies:
            >
            > Items Customers Parts
            > |
            > Parts
            >
            > Note that XML-DBMS allows you to specify the root
            > you want, then follows
            > the hierarchy to the leaves. In other words, I need
            > a separate map file
            > for the following hierarchy, since it omits the
            > parts table:
            >
            > Orders
            > / \
            > Items Customers
            >
            > I also need different map files for other
            > hierarchies, such as the
            > following:
            >
            > Parts Customers etc.
            > | |
            > Items Orders
            > |
            > Items
            > |
            > Parts
            >
            > Furthermore, a map file can define multiple,
            > separate hierarchies
            > (disconnected graphs), although there is generally
            > no reason to do this.
            >
            > 2) The filter file defines three things:
            > a) Any "wrapper" elements that wrap the returned
            > data.
            > b) The root table to use and the select criteria for
            > that table.
            > c) Any additional filters between tables.
            >
            > For example, if I want to retrieve data starting
            > with order number 123
            > and getting all items with a quantity greater than
            > 10, Orders is my root
            > table, order number 123 is my root select criteria,
            > and quantity greater
            > than 10 is my additional filter criteria on the
            > items table.
            >
            > So, to answer your question, you need:
            >
            > 1) Different map files for different hierarchies.
            > 2) Different filter files for different filter
            > values.
            >
            > Note that which filters are used depends on which
            > tables are defined in
            > the hierarchy. For example, if I include a filter
            > for the Foo table but
            > there is no Foo table in the hierarchy, the Foo
            > filter is never used.
            > Similarly, if I include a filter for the Customers
            > table but specify
            > that the Items table is my root table, the Customers
            > filter will be
            > ignored since it is not on the branch of the
            > hierarchy starting with
            > Items.
            >
            > In summary, having different maps and filters is no
            > different than
            > having different SELECT statements in SQL. The only
            > difference is that
            > map and filter files are big and hard to read and
            > SQL is short and easy
            > to read.
            >
            > -- Ron
            >
            > dling61 wrote:
            > >
            > > One more question to follow up this.
            > >
            > > I have a small enterprise data model containing
            > about ten tables. I
            > > also have different queries to select tables. Some
            > of them perform
            > > join operations.
            > >
            > > I want to have a single filter document to cover
            > all the queries I
            > > have. But it seems like XML-DBMS to construct
            > every result set based
            > > on each filter defined in filter document. If I
            > just want to restieve
            > > data from the customer table, XML-DBMS still go
            > through all the
            > > filters defined and process "select". Is that
            > right?
            > >
            > > Do I have to put different filters into different
            > filter files in my
            > > case? Plus, I do want to use retrieveDocumentBySQL
            > in this case.
            >


            __________________________________________________
            Yahoo! - We Remember
            9-11: A tribute to the more than 3,000 lives lost
            http://dir.remember.yahoo.com/tribute
          • Ronald Bourret
            ... I can t say if it s reasonable or not. It doesn t sound easy. How does the user enter their query? Do they just type things in (which means you need to
            Message 5 of 9 , Sep 12 11:08 AM
            • 0 Attachment
              Dongling Ding wrote:

              > In my application a user interface accepts query
              > requests from users. That means during the run time I
              > have to figure out which map and filter file can be
              > applied for a query, and then pass those into
              > retrieveDocument(). Also, I have to maintain many map
              > and filter files. Is that reasonable?

              I can't say if it's reasonable or not. It doesn't sound easy.

              How does the user enter their query? Do they just type things in (which
              means you need to parse their input) or are they selecting from lists,
              etc.?

              If the user is selecting from lists, etc., you can do one of two things:

              1) Limit the number of choices that the user has. You can then tie each
              choice directly to map and filter files.

              2) Build the Map and FilterSet objects yourself, based on user input.
              That is, write an editor for Maps and FilterSets. This is much more
              difficult because (a) you need to understand the Map and FilterSet
              objects, and (b) you have to build the Map and FilterSet objects
              correctly (the code for doing this does a limited number of checks). For
              more information see the ...xmldbms.maps and ...xmldbms.filters
              packages.

              > What about XQuery? Is that going to address the above
              > issues? I hope it will.

              Probably. If you were using XQuery, you could allow the user to either
              (a) type in an XQuery statement or (b) graphically build an XQuery
              statement. In the first case, you would simply pass the user input to an
              XQuery engine. In the second case, you would build an XQuery statement
              from the user's input and pass it to an XQuery engine. Both are probably
              easier than using XML-DBMS, although building a graphical XQuery editor
              is probably a lot of work.

              By the way, if you're looking for an XQuery engine, try XMLizer [1] from
              E-XMLMedia. It's the only one I've heard of that's built over JDBC,
              although there are probably others. It is a commercial product.

              -- Ron

              [1] http://www.e-xmlmedia.com/prod/xmlizer.htm
            • Dongling Ding
              ... There are list of queries to be chose. ... That is what I am doing right now. But I view this as a workaround. At this stage we can live with this. ... I
              Message 6 of 9 , Sep 12 2:58 PM
              • 0 Attachment
                > How does the user enter their query? Do they just
                > type things in (which
                > means you need to parse their input) or are they
                > selecting from lists,
                > etc.?

                There are list of queries to be chose.
                >
                > If the user is selecting from lists, etc., you can
                > do one of two things:
                >
                > 1) Limit the number of choices that the user has.
                > You can then tie each
                > choice directly to map and filter files.

                That is what I am doing right now. But I view this
                as a workaround. At this stage we can live with this.

                > > What about XQuery? Is that going to address the
                > above
                > > issues? I hope it will.
                >
                > Probably. If you were using XQuery, you could allow
                > the user to either
                > (a) type in an XQuery statement or (b) graphically
                > build an XQuery
                > statement. In the first case, you would simply pass
                > the user input to an
                > XQuery engine. In the second case, you would build
                > an XQuery statement
                > from the user's input and pass it to an XQuery
                > engine. Both are probably
                > easier than using XML-DBMS, although building a
                > graphical XQuery editor
                > is probably a lot of work.

                I am hoping XML-DBMS can implement Xquery in the
                near future. If not, I probabley need to think about
                other solutions. We're not considering commercial
                products right now.

                Thanks

                Dongling

                __________________________________________________
                Do you Yahoo!?
                Yahoo! News - Today's headlines
                http://news.yahoo.com
              • Ronald Bourret
                ... Don t hold your breath. I have no plans to implement XQuery any time soon. For a list of XQuery implementations (some Open Source), see:
                Message 7 of 9 , Sep 13 9:06 AM
                • 0 Attachment
                  Dongling Ding wrote:
                  > I am hoping XML-DBMS can implement Xquery in the
                  > near future. If not, I probabley need to think about
                  > other solutions. We're not considering commercial
                  > products right now.

                  Don't hold your breath. I have no plans to implement XQuery any time
                  soon. For a list of XQuery implementations (some Open Source), see:

                  http://www.w3.org/XML/Query

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