Niclas Hedhman a écrit :
On Tue, Oct 2, 2012 at 6:46 PM, Paul Merlin<[email protected]> wrote:
On the other side, it's possible to support RegExp search on several
engines. About SQL, many RDBMS support the REGEXP query operator or other
mecanisms.
Which ones? I need to update my SQL knowledge I guess...
MySQL, SQLite and H2 support the standard REGEXP query operator.
PostgreSQL supports the various operators (SIMILAR, ~, REGEXP_* etc..).
Oracle supports REGEXP_LIKE query operator.
For Apache Derby, as an example, we could use a "custom function" which
is the way Derby is meant to be extended.
I don't think this is too much asking to a RDBMS to handle regex natively.
Of course it's vendor hell, we're talking about SQL right :) but both
entitystore-sql and indexing-sql are done in a way that allows us to
support various vendors even if their differences are complex (thanks to
java-sql-generator).
entitystore-sql support PostgreSQL, MySQL and Apache Derby.
I have local changes that add support for embedded SQLite and H2 (plus
documentation) and will push them in a few of days.
For now indexing-sql only work on PostgreSQL but I plan to add other
RDBMS support once Query API support is full.
Plus, and after thinking a bit more about it, doing it as a post-filter will
be extremely complex/slow as the MatchesSpecification could be nested in a
complex Query. In fact I simply don't see how to do it out of the underlying
engine except by doing many queries and "manual" filtering along the way,
solution that I don't see as viable.
Yes, I don't find that doable. And my suggestion was a separate thing
altogether, not automatic from syntax tree analysis.
Would using Iterables.filter(...) to post-filter in application code
fullfill the usecase you have in mind?
/Paul
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
