GeoTools

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

Ascending order - Click to sort in descending order
Hide
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Vote (0)
Watch (1)

Dates

  • Created:
    Updated: