Jody Garnett ha scritto:
...snip...
>> * I cannot test DB2 and ArcSDE. If I commit is there anyone able to
>> run the tests? The encoded filter does not change, but I've made so
>> that if the simplification returns Filter.INCLUDE, no where clause is
>> created at all ('Select ... from ... where true' is just silly).
>>
> ArcSDE is now mostly doing its own thing; I will let you know tomorrow
> if I can run tests (I need to confirm that my ArcSDE instance still works).
> As for DB2 I do not have it installed locally; we will need to ask
> around for another developer to help out.
David, you around? :)
>> * Are the filter encoders the right place to perform the
>> simplification logic? For sure it's the minimal modification giving
>> the best overall usage of the algorithm, but I'm wondering if the
>> simplification is the duty of the encoder, or of the class calling it.
>>
> I would ask each DataStore developer to apply any simplifications they
> know of prior to encoding; the fact that you have
> SimplyfingFilterVisitor for them to start from is just great. I imagine
> some datastores would like to rename functions or fold in some
> optimizations prior to encoding.
>
> The case where a filter has just been split is special; I would expect
> each side of the split could be simplified prior to use.
Yep.
>> I've checked, doing the simplification outside of the encoders would
>> result in a much larger patch and would require me to touch code I'm
>> not familiar with, yet I would like to hear your opinion.
> Can you tell me more about what this patch would involve? Or an area
> where you are concerned?
What I meant is, to ensure the same coverage as the one offered in
applying the simplification inside the encoder, I would have to change
code that I'm not familiar with (e.g., the ArcSDE data store).
But I'm absolutely ok in just applying the simplification in
JDBC1DataStore and have every other maintainer apply in their own
datastore as they see fit.
About places where the simplification could be carried out, we
have the WFS datastore.
>> If the other devs prefer to see the simplification called in the
>> caller class I can just move the simplification calls into
>> JDBC1DataStore to cover the the jdbc classic case, that would leave
>> out ArcSDE and H2 thought.
>>
> I would personally prefer this; and would encourage ArcSDE and H2
> datastores to pick this simplification up. I imagine this may also be
> called from ShapefileDataStore and other locations if needed?
Cool, works for me. I'll commit a patch in this direction then.
Cheers
Andrea
-------------------------------------------------------------------------
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
