I think you have answers my question: we do have query hints for extra
control over data store interaction, but for this purpose it is not
connected close enough to filter encoding for your purpose.
I feel a bit odd opening a new kind of custom filter interface, when we
have worked very hard not to do so in the past.
Other option you may of already considered is to handle this as a function
that evaluates to true/false. Something like *native(query, fallback)*. The
first parameter would be SQL , the second a fallback value to be used when
not run on a database.
- I guess this is just not optimizable enough since you are focused on
filter splitters
- The true/false is not a very good contract, it would be handy to run a
native expression
- The net effect would be similar to parametrized views in that any SLD
using the filter or expression could still be portable (with reduced
utility)
On Wed, Mar 21, 2018 at 11:08 AM Nuno Oliveira wrote:
> Hi Jody,
>
> No sure I understand your comment:
>
>1. you mean there is already something similar that can be done with
>query hints ?
>2. or you mean we could use a query hint for this ?
>
> That say, one my first approaches was to take advantage of query hints but
> I step on to many limitations, just to *name* a few:
>
>- query hints at best allows us to say, please happen this to the
>final query that will be send to the data store, but doesn't allow us to
>build a filter the way we need it (OR, AND, nested, etc ...)
>
>
>- the native filter provides a more harmonized approach, the query
>hint would have to be managed explicitly in every part of the code where
>the final query that will be send to the data store is created, this would
>quickly become a nightmare (note this is not specific to JDBC data store)
>
>
>- having a filter allows us to take advantage of all the existing
>wiring and processing that involves filters visitors, e.g. capabilities
>support, filters splitter, etc ...
>
> Another thing that is worth mentioning, is that for most of the use cases
> I can think of being able to use a filter is more *compatible* for the
> invokers than setting up a query hint.
> Kind regards,
>
> Nuno Oliveira
>
>
> On 03/21/2018 01:59 AM, Jody Garnett wrote:
>
> do we not have query hints for this purpose?
> On Tue, Mar 20, 2018 at 12:07 PM Nuno Oliveira <
> nuno.olive...@geo-solutions.it> wrote:
>
>> Hi Andrea,
>> thanks for the feedback, please see my answers bellow:
>>
>>
>> On 03/20/2018 10:21 AM, Andrea Aime wrote:
>>
>> Hi Nuno,
>> last time a new type of filter was in this commit:
>>
>> https://github.com/geotools/geotools/commit/
>> 47e9259d74482b92244b4dd301363b434e382baf
>>
>> Thankfully now there are default methods, allowing for quite a bit less
>> painful extension.
>>
>>
>> Thanks, yes default methods help indeed.
>>
>>
>> Overall I see where this need comes from and agree with it, a few
>> notes/questions off the top of my head:
>>
>>- Can you share how you intend to implement NativeFilter? Is it an
>>interface with store specific implementations, or does it have a single
>>one? Which stores will receive a sample implementation of the concept?
>>
>>
>> My idea is to create an interface (this will help with filter visitors):
>>
>> public interface NativeFilter extends Filter {
>>
>> Expression getNative();
>> }
>>
>> and then provide a default implementation for it, this default
>> implementation should be enough for most use cases.
>>
>> The JDBC data store will be the first one receiving support for it.
>>
>>
>>
>>- Make sure the functionality is open for programmers but not from
>>the web (e.g., one cannot setup a XML or CQL filter using it
>>
>>
>> Yes this is an important point indeed, no XML binds or CQL support will
>> be implemented. The Filter to CQL visitor will throw an exception.
>>
>>
>>
>>- Properly document the intended usage of it including notion of
>>pre/post filter splitting, e.g., if a NativeFilter is supported, but it's
>>OR-ed with another bit using an unsupported filter function, it will end
>> in
>>the post, in memory evaluation, and will blow up.This is unavoidable, but
>>should not be a surprise for users.
>>
>>
>> Yep.
>>
>>
>> Cheers
>> Andrea
>>
>>
>>
>>
>>
>> On Mon, Mar 19, 2018 at 11:07 PM, Nuno Oliveira <
>> nuno.olive...@geo-solutions.it> wrote:
>>
>>> Hi all,
>>>
>>> Recently I have been dealing with some use cases that require the
>>> ability to inject some native filters,
>>> specific for each feature type and non static over time, to the final
>>> native query build by GeoTools and
>>> send to the data store.
>>>
>>> For example, the content of a feature type is partially controlled by an
>>> external service who provides a non
>>> static native query (the request changes over time) that filters the
>>> content that should be show.
>>>
>>> Another use case is a complex authorization