The idea sounded fine Gabriel.
I was entertaining a similar idea when faced with large FidFilters that could
not be encoded into PostGIS. I ended up with a workaround (splitting up the
FidFilter into batches of 800), but the better would be for the JDBCDataStore
to break things up into multiple SELECT statements; and then taking the time to
process each result set in turn.
But yeah detecting when when the PropertyName cannot be encoded seems fine,
returning Filter.EXCLUDE seems strange (as you kind of mean to include the
content in your request from SQL, and then you are going to filter them after
them on the Java side. I looked around to see if you could use Expression.NIL
as a placeholder (for the missing PropertyName) but cannot think of a smooth
way to make that work. It would involve teach the filter simplification code
about Expression.NIL and asking it to strip that out of the query prior to SQL
generation.
--
Jody Garnett
On Thursday, 28 June 2012 at 9:47 PM, Gabriel Roldan wrote:
> ok, if there are no objections so far then I'm inclined to commit the
> patch to trunk. Raise your concerns now?
>
>
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
GeoTools-Devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
