GeoTools
  1. GeoTools
  2. GEOT-2247

Create a JDBCFilterToSQL to factor out common needs and issues

    Details

    • Type: Task Task
    • Status: Reopened Reopened
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 2.5.2
    • Fix Version/s: 2.5.9
    • Component/s: jdbc
    • Labels:
      None

      Description

      All JDBC(ng) related filter to sql have at least two common issues:

      • they need to encode geometry literals with the same srid as the properties they are compared against, otherwise the spatial databases will throw an incompatible srid error
      • they can leverage the SQLDialect to encode the geometry literals

      A common superclass can handle the basic needs, and a prepared statement subclass can deal with the further specialized needs of a PS based dialect.
      Or we can have just one class with a configuration parameter, which might help out implementors looking out to have both a PS and a non PS dialect around (for performance issues).

        Activity

        Hide
        Justin Deoliveira added a comment -
        So to understand you want to create a JDBCFilterToSQL which extends FIlterToSQL? And then further subclass to PreparedFilterToSQL? Is the problem that FitlerToSQL is in jdbc which does not have any of the jdbc-ng stuff as a dependency?
        Show
        Justin Deoliveira added a comment - So to understand you want to create a JDBCFilterToSQL which extends FIlterToSQL? And then further subclass to PreparedFilterToSQL? Is the problem that FitlerToSQL is in jdbc which does not have any of the jdbc-ng stuff as a dependency?
        Hide
        Andrea Aime added a comment -
        Yes, and it should not have those deps too, since FilterToSql is used by ArcSDE as well... it's probably better to move it to main?
        Anyways, the plain is like you have suggested. What I need is the concept of the native SRID stored inside the descriptor metadata and access to the SQLDialect in order use it for encoding string literals.
        Show
        Andrea Aime added a comment - Yes, and it should not have those deps too, since FilterToSql is used by ArcSDE as well... it's probably better to move it to main? Anyways, the plain is like you have suggested. What I need is the concept of the native SRID stored inside the descriptor metadata and access to the SQLDialect in order use it for encoding string literals.
        Hide
        Andrea Aime added a comment -
        Fixed on trunk (pg-ng is not backported to 2.5.x, does not make much sense so far since it's clearly still inferior to the old one, which has proper paging support, works with views and on tables without a pk).
        Show
        Andrea Aime added a comment - Fixed on trunk (pg-ng is not backported to 2.5.x, does not make much sense so far since it's clearly still inferior to the old one, which has proper paging support, works with views and on tables without a pk).
        Hide
        Andrea Aime added a comment -
        Gah, closed the wrong one! (I was meaning to close the non ps dialect for postgis one...)
        Show
        Andrea Aime added a comment - Gah, closed the wrong one! (I was meaning to close the non ps dialect for postgis one...)

          People

          • Assignee:
            Andrea Aime
            Reporter:
            Andrea Aime
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated: