Proposal: introduce the concept of a native DataProvider filter

When I implemented a concrete implementations of Vaadin DataProvider (the JpaDataProvider, the EntityDataProvider and SqlDataProvider data provider implementations) it became clear that those data providers can’t simply accept any type of filters: for example SqlDataProvider can only accept filters that can be turned into valid SQL92 where clauses. Another example would be a JPADataProvider which can only accept JPA Criteria API classes. Neither of those data providers are for example able to accept a String filter (as provided by the ComboBox) since it’s not clear what kind of matching is to be used, and which columns should be matched. Also, nosql data providers will introduce their own set of filters which would be quite incompatible with SQL-based data providers.

I believe it would be useful to introduce a concept of filters that are native to a particular DataProvider implementation:

• JPADataProvider would only accept JPA Criteria API classes;
• SqlDataProvider would introduce its own set of filters it accepts
• MongodbDataProvider would introduce its own set of filters it accepts
• ListDataProvider accepts a SerializablePredicate<T> as its filter
• An app-proprietary RestDataProvider using proprietary set of filters to fetch data

It would make no sense to try to convert Mongodb filters into SqlDataProvider and vice versa, therefore there should be no such support from the DataProvider.

Originally it was believed that, given a proper converter, a DataProvider could be able to use foreign filters (for example filters produced by Vaadin components - ComboBox provides search text as typed in by the user as String). However, it is not clear how to match String against a SQL table or a JPA entity. Also, the matching may tend to differ for different usage scenarios: say, one ComboBox shows entity Person while another shows entity Address and both of those entities are produced by the JPADataProvider.

That’s why ComboBox employs call-site filter conversion: it implements (Vaadin8) HasFilterableDataProvider.setDataProvider(DataProvider, SerializableFunction) and requires the user to provide a proper String->F converter for every ComboBox.

I would therefore propose to introduce the concept of native filters into the DataProvider javadoc. This will allow us to rewrite DataProvider.withConfigurableFilter() to only combine filters of type F and produce a filter of type F. That would make the function way simpler to use since it will use two generic parameters instead of four. This would also make the filter conversion in DataProvider unnecessary.

[Legioth]

If the withConvertedFilter() method would be dropped, it would mean that the UI logic that e.g. configures a ComboBox would also have to be concerned with backend technologies such as JPA. This would to some degree be against the separation of concerns that many architectures try to maintain.

By having both DataProvider.withConvertedFilter(SerializableFunction) and HasFilterableDataProvider.setDataProvider(DataProvider, SerializableFunction), the application developer can choose in which part of the code they want to do the conversion.

[mvysny]

I see your point. It seems that the API is hitting Java limitations and can’t be done in a clean and simple manner. We would need extension methods to introduce withFilter() methods for particular filter types only (e.g. fun <T> DataProvider<T, JPAFilter>.withFilter(...)), but that’s Kotlin-only. I guess there is nothing more we can do, please feel free to close this issue as won’t fix.