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

FilterConditions bugfix and code contribution

Expand Messages
  • Peter V. Mikhalenko
    Hello, Ronald! Maybe I am using old version of XMLDBMS2, but I ve found that IN operator in WHERE clauses within filter sets didn t work. After several time
    Message 1 of 4 , Jan 14, 2003
    View Source
    • 0 Attachment
      Hello, Ronald!

      Maybe I am using old version of XMLDBMS2, but I've found that IN operator in
      WHERE clauses within filter sets didn't work. After several time debugging
      file FilterConditions.java, I found a few things:

      1) in parseCondition(int) function: (sorry, can not give line numbers
      because I've changed slightly the file)
      The "dollar = i;" should be executed before calling checkINOperator(),
      because it uses the "dollar" variable.

      2) in checkINOperator() function:
      in the "N" state of automata the "state = I;" execution missed before
      breaking.

      After that, the correct version of checkINOperator should be:
      ------------------------------------------
      private boolean checkINOperator(char[] src, int pos)
      {
      int state;

      // Parse backwards and see if we are using an IN operator.

      state = WHITESPACEAFTERPAREN;
      for (int i = pos - 1; i >= 0; i--)
      {
      switch (state)
      {
      case WHITESPACEAFTERPAREN:
      // If the current character is whitespace, continue parsing.
      // Otherwise, fall through to check if we have an opening
      parenthesis.

      if ((src[i] == 0x20) || (src[i] == 0x0d)) break;
      state = PAREN;
      // WARNING! This falls through to the next case.

      case PAREN:
      if (src[i] != '(') return false;
      state = WHITESPACEBEFOREPAREN;
      break;

      case WHITESPACEBEFOREPAREN:
      // If the current character is whitespace, continue parsing.
      // Otherwise, fall through to check if we have an 'N'.
      if ((src[i] == 0x20) || (src[i] == 0x0d)) break;
      state = N;
      // WARNING! This falls through to the next case.

      case N:
      if ((src[i] != 'n') && (src[i] != 'N')) return false;
      state = I;
      break;

      case I:
      if ((src[i] != 'i') && (src[i] != 'I')) return false;
      state = WHITESPACEBEFOREIN;
      break;

      case WHITESPACEBEFOREIN:
      if ((src[i] == 0x20) || (src[i] == 0x0d)) return true;
      return false;
      }
      }
      return false;
      }
      -----------------------------------------------

      Also I added the checkLIKEOperator, if you wish, I can send you the code.
      I needed it because XMLDBMS has pretty poor functionality in creating LIKE
      SQL-expresions, even in an easiest way - "%$param%". I think you will agree
      with me that SQL expressions
      column LIKE $param
      and
      column = $param
      are equal and in your implementation give the same result.


      __
      Peter V. Mikhalenko
      Lead Developer
      Sigent LLC
      peter@...
    • Ronald Bourret
      It looks like you are correct. I haven t yet integrated/tested the code because I noticed that there is no way to use IN clauses with Transfer, so I want to
      Message 2 of 4 , Jan 17, 2003
      View Source
      • 0 Attachment
        It looks like you are correct. I haven't yet integrated/tested the code
        because I noticed that there is no way to use IN clauses with Transfer,
        so I want to figure that out at the same time.

        Also, please send me the code for working with LIKE operators. If it
        isn't too big, just post it to the list. (Note that the list does not
        accept attachments.) Otherwise, please send it to me directly.

        Thanks,

        -- Ron

        "Peter V. Mikhalenko" wrote:
        >
        > Hello, Ronald!
        >
        > Maybe I am using old version of XMLDBMS2, but I've found that IN operator in
        > WHERE clauses within filter sets didn't work. After several time debugging
        > file FilterConditions.java, I found a few things:
        >
        > 1) in parseCondition(int) function: (sorry, can not give line numbers
        > because I've changed slightly the file)
        > The "dollar = i;" should be executed before calling checkINOperator(),
        > because it uses the "dollar" variable.
        >
        > 2) in checkINOperator() function:
        > in the "N" state of automata the "state = I;" execution missed before
        > breaking.
        >
        > [code snipped]
        >
        > Also I added the checkLIKEOperator, if you wish, I can send you the code.
        > I needed it because XMLDBMS has pretty poor functionality in creating LIKE
        > SQL-expresions, even in an easiest way - "%$param%". I think you will agree
        > with me that SQL expressions
        > column LIKE $param
        > and
        > column = $param
        > are equal and in your implementation give the same result.
      • Ronald Bourret
        Thanks, Peter. This code is now fixed and checked in to the CVS tree. I also added a fix to Transfer so that you can use parameters in IN clauses through
        Message 3 of 4 , Jan 18, 2003
        View Source
        • 0 Attachment
          Thanks, Peter. This code is now fixed and checked in to the CVS tree.

          I also added a fix to Transfer so that you can use parameters in IN
          clauses through Transfer. This is very useful when you want to retrieve
          a set of things, such as a set of sales orders, each of which has a
          different sales order ID.

          Note that you can't use the change to Transfer just by checking out
          Transfer. This is because I have made a number of changes since alpha 3
          that are backwards-incompatible with alpha 3. If you want to use this,
          you will need to update all classes.

          -- Ron

          "Peter V. Mikhalenko" wrote:
          >
          > Hello, Ronald!
          >
          > Maybe I am using old version of XMLDBMS2, but I've found that IN operator in
          > WHERE clauses within filter sets didn't work. After several time debugging
          > file FilterConditions.java, I found a few things:
          >
          > 1) in parseCondition(int) function: (sorry, can not give line numbers
          > because I've changed slightly the file)
          > The "dollar = i;" should be executed before calling checkINOperator(),
          > because it uses the "dollar" variable.
          >
          > 2) in checkINOperator() function:
          > in the "N" state of automata the "state = I;" execution missed before
          > breaking.
          >
          > After that, the correct version of checkINOperator should be:
          > ------------------------------------------
          > [code snipped]
          > -----------------------------------------------
          >
          > Also I added the checkLIKEOperator, if you wish, I can send you the code.
          > I needed it because XMLDBMS has pretty poor functionality in creating LIKE
          > SQL-expresions, even in an easiest way - "%$param%". I think you will agree
          > with me that SQL expressions
          > column LIKE $param
          > and
          > column = $param
          > are equal and in your implementation give the same result.
        • Ronald Bourret
          I am thinking about something more general. For example, we could just have a general text-replacement scheme similar to entities in XML. For example, you
          Message 4 of 4 , Jan 24, 2003
          View Source
          • 0 Attachment
            I am thinking about something more general. For example, we could just
            have a general text-replacement scheme similar to entities in XML. For
            example, you could have filter conditions like:

            LIKE &foo
            BETWEEN &bar AND &baz

            and property values like:

            &foo=%bourret
            &bar=100
            &baz=1000

            This would allow people to parameterize anything they wanted. By using &
            instead of $ to indicate a text-replacement parameter, it would also
            mean that text-replacement parameters are separate from column
            parameters. This is important, since column parameters are sent to the
            database, while text-replacement parameters are processed by XML-DBMS.

            A couple of notes:

            1) Text-replacement parameters themselves would not be parsed. That is,
            I can't play games like having a filter condition:

            &condition

            and passing the property

            &condition=SONumber = '$SONumber'

            If I do this, then what is passed to the database is:

            SONumber = '$SONumber'

            not:

            SONumber = ?

            2) You escape an ampersand the same way you escape a dollar sign. That
            is, you use a backslash. For example:

            Name = 'Smith \& Jones'

            What do you think?

            -- Ron

            "Peter V. Mikhalenko" wrote:

            > > Thanks! I took a quick look at the code. It appears that you specify a
            > > condition of the form:
            > >
            > > LIKE '$MyParam'
            > >
            > > and the code constructs a LIKE clause of the form:
            > >
            > > LIKE '%MyValue%'
            > >
            > > where value is the value of the "like" parameter. Is this correct?
            >
            > Exactly.
          Your message has been successfully submitted and would be delivered to recipients shortly.