Details

    • Type: Improvement Improvement
    • Status: Open Open
    • Priority: Critical Critical
    • Resolution: Unresolved
    • Affects Version/s: 2.5-M0
    • Fix Version/s: 2.7.6
    • Component/s: main
    • Labels:
      None

      Description

      The goal here is to have a Capabilities wrapper around a opengis FilterCapabilities data structure that we can use as method compatible replacement for the old FilterCapabilities class:

      Capabilities capabilities = new Capabilities( filterCapabilities );
      capabilities.addType( Beyond.class ); // add to SpatialCapabilities
      capabilities.addType( PropertyIsEqualTo.class ); // add to ScalarCapabilities
      capabilities.addName( "NullCheck" ); // will enable PropertyIsNull use
      capabilities.addName( "MUL" ); // will enable hasSimpleArithmatic
      capabilities.addName( "random" ); // a function returning a random number
      capabilities.addName( "Length", 1 ); // single argument function
      capabilities.addName( "toDegrees", "radians" ); // single argument function
      capabilities.addName( "length", "expression" );
      
      if( capabilities.fullySupports( filter ) ){
          // encode as SQL
      }
      
      Capabilities capabilities2 = new Capabilities();
      
      capabilities2.addAll( capabilities );
      capabilities2.addAll( Capabilities.LOGICAL ); // Capabilities.LOGICAL is a FilterCapabilities
      

      The proposal page is here:

        Issue Links

          Activity

          Hide
          Jody Garnett added a comment -
          This work is now committed on trunk, and will await public review before being closed.
          Show
          Jody Garnett added a comment - This work is now committed on trunk, and will await public review before being closed.
          Hide
          Gabriel Roldan added a comment -
          Hi Jody, I guess the missing bit for a wider adoption of org.opengis.filter.FitlerCapabilities is the port of PostPreProcessFilterSplittingVisitor, which I've done for WFS 1.1.
          Yet, porting the test suite for it leads to failures since both IsFullySupportedFilterVisitor and IsSupportedFilterVisitor implement the following:

          public Object visit( Function function, Object extraData ) {
                  ScalarCapabilities scalar = capabilities.getScalarCapabilities();
                  if( scalar == null ) return false;
                  
                  ArithmeticOperators operators = scalar.getArithmeticOperators();
                  if( operators == null ) return false;
                  
                  Functions functions = operators.getFunctions();
                  if( functions == null ) return false;
                  
                  // Note that only function name is checked here
                  FunctionName found = functions.getFunctionName( function.getName() );
                  if( found == null ) return false;
                  
                  return found.getArgumentCount() == function.getParameters().size();
          }

          Note that the last method's line compares the number of arguments in the function instance and the FunctionName declared argument count. I know arg count is a hot topic and not sure if we already solved it. Yet, I keep on thinking this last check is unnecessary and we should be ok with just matching the function name, since as per the spec and our implementation too there can't exist two functions with the same name and different number of arguments.

          And since when adding support for a function to an org.geotools.filter.Capabilities FitlerCapabilities wrapper I cannot know the number of arguments beforehand.. what about eliminating that last check and returning true if the function names match?


          Show
          Gabriel Roldan added a comment - Hi Jody, I guess the missing bit for a wider adoption of org.opengis.filter.FitlerCapabilities is the port of PostPreProcessFilterSplittingVisitor, which I've done for WFS 1.1. Yet, porting the test suite for it leads to failures since both IsFullySupportedFilterVisitor and IsSupportedFilterVisitor implement the following: public Object visit( Function function, Object extraData ) {         ScalarCapabilities scalar = capabilities.getScalarCapabilities();         if( scalar == null ) return false;                  ArithmeticOperators operators = scalar.getArithmeticOperators();         if( operators == null ) return false;                  Functions functions = operators.getFunctions();         if( functions == null ) return false;                  // Note that only function name is checked here         FunctionName found = functions.getFunctionName( function.getName() );         if( found == null ) return false;                  return found.getArgumentCount() == function.getParameters().size(); } Note that the last method's line compares the number of arguments in the function instance and the FunctionName declared argument count. I know arg count is a hot topic and not sure if we already solved it. Yet, I keep on thinking this last check is unnecessary and we should be ok with just matching the function name, since as per the spec and our implementation too there can't exist two functions with the same name and different number of arguments. And since when adding support for a function to an org.geotools.filter.Capabilities FitlerCapabilities wrapper I cannot know the number of arguments beforehand.. what about eliminating that last check and returning true if the function names match?

            People

            • Assignee:
              Unassigned
              Reporter:
              Jody Garnett
            • Votes:
              1 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated: