Menu
▾
▴
Re: [SMW-devel] [PATCH] Support LIKE in queries
|
From: Markus <ma...@ai...> - 2007-12-30 21:10:10
|
OK, my conclusion now was to support the following syntax: [[property% *subs?r*]] where ? and * represent _ and % in SQL. Some more remarks inline below. On Sonntag, 30. Dezember 2007, DanTMan wrote: > ^_^ ok, I thought we escaped with a \, which isn't something that normal > users would find easy to use. But a starting space escape is ok. > > I still would pick ~ as the best thing for use of REGEX and prefer a > different operator for wild cards > I guess the % is probably best for the wild card operator. Which brings > me the thought of: > > EQ: [[property::value]] > NEQ: [[property::!value]] > GT: [[property::>value]] > LT: [[property::<value]] > WILD: [[property::%value]] (Using ? and *) > > Also, I propose a few more additions since they will probably have some > good use to. > > GTEQ: [[property::>=3Dvalue]] > LTEQ: [[property::<=3Dvalue]] Rarely needed, but already possible by using disjunctions. > NWILD: [[property::!%value]] (Negated wild card) Maybe in the future if someone really needs it. > REGEX: [[property::~value]] or perhaps [[property::~/value/i]] (/ could > of course be replaced with !, [], etc... any valid in preg. Unlikely. Regexps are very complex and not at all efficient on a DB scale=20 (even LIKE is a problem here, which is why it is disabled by default). > NGT: [[property::#<value]] (Natural order greater than) > NLT: [[property::#>value]] (Natural order less than) > NGTEQ: [[property::#<=3Dvalue]] (Natural order greater than or equal to) > NLTEQ: [[property::#>=3Dvalue]] (Natural order less than or equal to) > > Of course, the REGEX one is provided that we can fix the issue of > colliding with Halo. > But on note of that negated wild card. I added that one for one primary > reason. Unlike any of the other things, you cannot negate a wild card > with any other format. (> can be negated with <=3D, eq with !, and regex > can negate things inside of it. But you can't negate a wild card) Also, > remember to escape things so that we can use (\* and \? to use those > literally; I could draft all the replaces needed, but I got to go do > something first) > As for the Natural order ones, if you don't know what those are for, > it's things like values of "1.2.3" and "1.12.3". Using a normal > it > thinks that "1.2.3" is greater than "1.12.3" because the third character > is a two and the third character in the other is a 1. But a natural > order properly distinguishes the second number as 12. PHP has functions > for these built in and would be nice for use. On "natural orders": datatypes in SMW usually come with an own "natural ord= er"=20 and all comparators refer to those already. Things like the version numbers= =20 you mentioned are problematic unless restricted, since they are again hard = to=20 implement on a DB level efficiently (this is of course different if the=20 format is somehow restricted). Note that PHP implementations of comparators= =20 do not help us, since the DB must do all the comparisons. Markus > > ~Daniel Friesen(Dantman) of: > -The Gaiapedia (http://gaia.wikia.com) > -Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG) > -and Wiki-Tools.com (http://wiki-tools.com) > > Markus Kr=F6tzsch wrote: > > On Samstag, 29. Dezember 2007, DanTMan wrote: > >> A lot of people are accustomed to the ? (single-character match) and * > >> (multi-character match) format. It would be easy to escape the '_'s and > >> '%'s in a match and then do a replace of ? to _ and * to %. (A little > >> preg and \ could still easily escape those.) > > > > Yes, I agree to that. I think, if nobody objects, this fixes the pattern > > syntax. So it remains to find a good symbol for the comparator. > > > >> I don't know about ~ though, in the languages I've used I recall ~ > >> having something to do with regex. I'd rather save that character for = in > >> case we want to be able to use the REGEXP matching inside of SQL. > >> > >> From what I remember, I think most people with only a little insight > >> into technical stuff, would adjust easiest to using this set: > >> =3D Equals > >> > >> > Greater than > >> >=3D Greater than or equal to > >> > >> < Less than or equal to > >> ! Not > >> * Multi-character match > >> ? Single-character match > >> ~ regex > > > > As a note: "=3D" is not available in parser function #ask, since it has= a > > special meaning as parameter assignment, as e.g. in "format=3Dtable". T= he > > query is distinguished from the other parameters and print requests in > > #ask since it has no =3D symbol and does not start on ?. > > > >> But I did have a thought about the @... It's not used anywhere afaik. > >> I did make a suggestion on using a pattern to separate the comparators > >> from the match value. It was using [[Property::comparitor::match]], but > >> as I now remember SMW lets you use :: to specify multiple properties. > >> However it may be a good idea if the separator was one which wouldn't > >> cause conflicting issues with other things. > > > > Maybe I should remark that the comparator we chose will never block any > > symbol from being used in values. You can always escape the initial > > comparator by inserting an initial space (which is ignored in all > > values). For instance, to look for pages with property value "<strange > > value>", one could write > > > > [[some property:: <strange value>]] > > > > whereas [[some property::<strange value>]] would be equivalent to > > > > [[some property::< strange value>]] > > > > which matches all values (alphabetically) smaller than "strange value>". > > So we can pick any comparator letter without conflicts. > > > >> @ is not commonly used and > >> does provide a little bit of a way for people to understand it's use. = Or > >> if you want a little farther from what can actually be used in a title > >> (To avoid clashing with things) the # is always invalid. > >> Say, [[prop::comp@match]] or [[prop::comp#match]]. So for a not [[Has > >> value::!@Value]] or [[Has value::!#Value]]. > > > > Basically, spaces already play the role of your proposed @ or #. > > > >> I'm probably droning on now... But what about finding a good separator > >> and allowing textual names ie: EQ[=3D], NOT/NEQ/[!] (!=3D could be tho= ught > >> of),LT[<], GT[>], REGEX(P)[~], LIKE[%_], wildcard[*?], etc... > > > > Not sure whether that would be better internationally. "<" seems to be > > more universally understood than "LT". > > > > Another remark: "::!" stands for inequality (NEQ), not for negation > > (NOT). It looks for pages that have some property value unequal to the > > one that was given, and it does not matter whether or not they also have > > some value that is equal. So a page that is annotated with > > [[property::1]] and > > [[property::2]] would match a query atom [[property::!1]]. > > > >> There also is the possibility of instead of a separator, using brackets > >> to encompass a comparator. I can hardly think of many places which wou= ld > >> use (NOT) at the start of a title ([[Has value::(NOT) Title]]) or, we > >> also have the {} and [] type brackets. [] is used by external links, b= ut > >> {} is only used in multiples as a template or variable bit but never h= as > >> use singularly, templates and values will have already been parsed out > >> so only the singles remain, and as a bonus, { and } are illegal in > >> titles. So [[Has value::{NOT} Title]] is guaranteed to never clash with > >> a legal title or match you can make. If you're worried about templates > >> and parsing issues, those can't occur when your using something like > >> {{{1}}} as the title ([[Has value:{NOT} {{{1}}}]]) so there's no clash. > >> The only potential class is if someone wants to use {{{comparator|EQ}}} > >> to specify the comparator. In that case, we could easily make { EQ } > >> valid (trim spaces), so "{ {{{comparator|EQ}}} }" would work. > > > > Yes, that would work too. But I am happy with our spaces (the fact that > > initial and trailing spaces are ignored in all property values is the k= ey > > to make that work, and I think there is no harm in assuming that). > > > > There is, in principle, no problem with having multi-char sequences for > > comparators, but I would prefer something that does not require > > internationalisation. So, given that we use * and ? instead of % and _, > > there are the following options: > > > > 1- [[property::%*substring*]] > > 2- [[property::#*substring*]] > > 3- [[property::~*substring*]] (clashes with Halo) > > 4- [[property::@*substring*]] > > 5- maybe more ... > > > > My order of preference would be 3, 1, 4, 2, and I opt for 1 due to the > > Halo issue. Further ideas and arguments are still welcome until Sunday > > evening, when we hope to release SMW 1.0. > > > > Cheers, > > > > Markus > > > >> But... now I'm droning a bit much... > >> > >> ~Daniel Friesen(Dantman) of: > >> -The Gaiapedia (http://gaia.wikia.com) > >> -Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG) > >> -and Wiki-Tools.com (http://wiki-tools.com) > >> > >> Markus Kr=F6tzsch wrote: > >>> On Freitag, 28. Dezember 2007, Yaron Koren wrote: > >>>> How about ~%substring% instead? The "~" is the symbol for pattern > >>>> matching in Perl and some UNIX languages, and it might be a clearer > >>>> indicator of function than "%". > >>> > >>> I would immediately use that, but IFRC the Halo extension has a simil= ar > >>> syntax for a custom editing-distance database function (requires > >>> modified MySQL version, and probably also has significant performance > >>> issues). > >>> > >>> So the question is whether we want to overwrite that (assuming that > >>> this particular Halo function is not used widely), or is there another > >>> idea for doing it? Other imaginable operators on my keyboard would be > >>> #, &, ?, @ -- none really as nice as ~ ... > >>> > >>> Markus > >>> > >>>> On Dec 27, 2007 2:16 PM, Markus Kr=F6tzsch <mak@aifb.uni-karlsruhe.d= e> > > > > wrote: > >>>>> Thanks. I have applied the patch, and added a way of configuring th= is > >>>>> feature: > >>>>> the parameter $smwgQComparators gives a (|-separated) list of > >>>>> supported comparators, and can be used to enable or disable any of = <, > >>>>> >, !, and %. By > >>>>> default its value is '<|>|!|%'. > >>>>> > >>>>> In this way one can also disable ! or even <, > if these are > >>>>> considered to be > >>>>> problematic. > >>>>> > >>>>> I wonder whether one should use another character instead of "%" as= a > >>>>> wildcard > >>>>> inside the pattern string, so that no double-% confusion can arise. > >>>>> Would * > >>>>> be an alternative or would it be too confusing w.r.t. the old <ask> > >>>>> print requests? What about +? According examples (preprocessing wou= ld > >>>>> in each case > >>>>> ensure full compatibility with SQL): > >>>>> > >>>>> - %%substring% > >>>>> - %*substring* > >>>>> - %+substring+ > >>>>> > >>>>> Cheers > >>>>> > >>>>> Markus > >>>>> > >>>>> On Donnerstag, 20. Dezember 2007, Asheesh Laroia wrote: > >>>>>> On Thu, 20 Dec 2007, Thomas Bleher wrote: > >>>>>>> Yesterday I needed LIKE queries for properties, so I added it to > >>>>>>> SMW (patch attached). It was surprisingly simple. > >>>>>> > >>>>>> This would be LIKE TOTALLY AWESOME to get in to Semantic MediaWiki. > >>>>>> > >>>>>> It would be great if later SMW could have Valgol support > >>>>>> <http://www.indwes.edu/Faculty/bcupp/things/computer/VALGOL.html>. > >>>>>> > >>>>>> -- Asheesh. > >>>>>> > >>>>>> P.S. In all total like seriousness, queries with LIKE support are a > >>>>>> good idea.... > >>>>>> > >>>>>> -- > >>>>>> The star of riches is shining upon you. > >>>>> > >>>>> -------------------------------------------------------------------= =2D- > >>>>>-- -- > >>>>> > >>>>>> This SF.net email is sponsored by: Microsoft > >>>>>> Defy all challenges. Microsoft(R) Visual Studio 2005. > >>>>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > >>>>>> _______________________________________________ > >>>>>> Semediawiki-devel mailing list > >>>>>> Sem...@li... > >>>>>> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > >>>>> > >>>>> -- > >>>>> Markus Kr=F6tzsch > >>>>> Institut AIFB, Univers=E4t Karlsruhe (TH), 76128 Karlsruhe > >>>>> phone +49 (0)721 608 7362 fax +49 (0)721 608 5998 > >>>>> ma...@ai... www http://korrekt.org > >>>>> > >>>>> -------------------------------------------------------------------= =2D- > >>>>>-- -- This SF.net email is sponsored by: Microsoft > >>>>> Defy all challenges. Microsoft(R) Visual Studio 2005. > >>>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > >>>>> _______________________________________________ > >>>>> Semediawiki-devel mailing list > >>>>> Sem...@li... > >>>>> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > >>> > >>> ---------------------------------------------------------------------= =2D- > >>>- > >>> > >>> ---------------------------------------------------------------------= =2D- > >>>-- This SF.net email is sponsored by: Microsoft > >>> Defy all challenges. Microsoft(R) Visual Studio 2005. > >>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > >>> ---------------------------------------------------------------------= =2D- > >>>- > >>> > >>> _______________________________________________ > >>> Semediawiki-devel mailing list > >>> Sem...@li... > >>> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Semediawiki-devel mailing list > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel =2D-=20 Markus Kr=F6tzsch Institut AIFB, Univers=E4t Karlsruhe (TH), 76128 Karlsruhe phone +49 (0)721 608 7362 fax +49 (0)721 608 5998 ma...@ai... www http://korrekt.org |