Justin Deoliveira ha scritto:
> Hi all,
>
> I have run into a situation where it would be nice to have the jdbc sql
> encoders to be moved over to the geoapi FilterVisitor interface, instead
> of implementing the old interface and having the FilterVisitorWrapper be
> used for backwards compatability.
>
> First the problem:
>
> Consider the following BinaryOperator:
>
> <PropertyIsEqualTo>
> <PropertyName>boolProperty</PropertyName>
> <Literal>1</Literal>
> </PropertyIsEqualTo>
>
> The problem with the current system is that we end up with an sql
> statement like this:
>
> WHERE boolProperty = '1'.
>
> Which fails for postgres, other databases may be able to convert. What I
> would like to do is have the context of the type around while encoding
> the literal "1". In this case know that I am encoding a boolean so be
> able to convert "1" to Boolean.TRUE.
Heh, a Geoserver user hit exactly the same issue yesterday, but on the
Oracle data store. I thought about handling this at the parsing level,
but encoding works as well.
> Half the battle has already been won. With the Converter interface the
> literal "1" can be easily converted to a boolean with the context
> Boolean.class.
>
> However, the problem is that individual elements of the filter are
> encoded in isolation so I have no way of knowing that the literal is
> being compared to a boolean at the end of the day.
>
> So... onto my proposal. This may be something that falls into our new
> process of needing a wiki page as it effects many modules ( every jdbc
> datastore ).
Indeed :-)
> The geoapi FilterVisitor uses the "extraData" parameter in all visit
> methods to provide extra context to visitors. For instance:
>
> visit( Literal, Object extraData );
>
> This would solve the problem nicely, as I could pass in the type of the
> literal as extra data. So the "visit( PropertyIsEqualTo equalTo )"
> method of SQLEncoder would look something like:
>
> Object visit( PropertyIsEqualTo equalTo, Object extraData ) {
>
> Expression left = equalTo.getExpression1();
> Expression right = equalTo.getExpression2();
>
> //encode left hand side
> left.visit( this, extraData );
>
> //check for PropertyName to get the type
> Object hint = null;
> if ( left intsanceof PropertyName ) {
> //evaluate against the feature type to get the class
> hint = (Class) left.evaluate( featureType );
Oh, so PropertyName wold be able to evaluate both against a Feature
and a FeatureType, returning different results?
Anyways, the idea seems to be working fine :-)
Cheers
Andrea
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
