Versioning may make PrePostFilterSplitter throw a StackTraceOverflow
--------------------------------------------------------------------
Key: GEOT-2071
URL: http://jira.codehaus.org/browse/GEOT-2071
Project: GeoTools
Issue Type: Task
Components: data versioning postgis
Affects Versions: 2.5.0
Reporter: Andrea Aime
Assignee: Andrea Aime
Fix For: 2.5.1, 2.6-M0
Various versioning requests are building big fid filters that are then turned
into sequences of or-ed PropertyIsEqualsTo against the native feature type (as
opposed to the one that's shown to the world, which does not have the
versioning attributes). The chains look like:
{code}
[pkAtt = x] or [[[pkAtt = y]] or [pkatt = z]] or ...
{code}
that is a nesting of or-s. Given the recursive nature of the filter splitter,
such chain can trigger a stack overflow if big enough.
One way to address this could be to turn the filter splitter into a iterative
algorithm, but that would be very complex.
It's a lot easier to make versioning build a flat or chain insead, that is
[pkatt = x] or [pkatt = y] or [pkatt = z] or ...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
