[SMW-devel] SQL in SMW
When the developers are adding things to SMW's SQL Store could they stick to a few guidelines: A) When doing extremely simple SQL statements never do something like: $db-query( SELECT title FROM $tablename, 'SMW::getQueryResult:DEBUG'); It's quite horrifying to see people building raw SQL queries when there are direct helper functions there to abstract them. That there is a strait out $db-select( $tablename, 'title', null, 'SMW::getQueryResult:DEBUG' ); And I even see the same thing with inserts and other statements. B) Something much more important... NEVER use DROP alone. SMW creates temporary tables, not real ones. So the statement should ALWAYS be DROP TEMPORARY. There is absolutely no 4.0 compatibility issue, 4.0 simply ignores the TEMPORARY, as defined in the manual. Additionally this avoids any possible accident of somehow dropping one of MW's core tables. But the biggest issue here, is that using DROP without the TEMPORARY means that the MediaWiki user now needs to have DROP permissions to be able to run. That is not secure, users of a web app should never be able to use a DROP function. I'm going to be fixing up a little later, namely B, but I'd like the devs here to know about the methods that are meant to be used. Actually I also have an issue with SMW_setup.php, that maintenance script requires that you either give your Wiki user complete database permissions, which is insecure. Or that you input a administrative username and a password on the cli. And that's insecure to. MediaWiki's update.php does not require either of this to be done, that is what AdminSettings.php is for, SMW_setup.php should not be requiring things like this when MediaWiki already supports more secure methods of doing things. I'm probably going to be modifying that one sometime in the future to fix it to. -- ~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) - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] Special notation of numbers
:/ I need to remember to use Reply to all on these sf lists.
Well, actually it's not just the US, and not just imperial.
For my use, it's on the Narutopedia. The databooks (Japanese ones) use
the #'# format, so I wanted to be able to let users just input the
sizes in the same format as the databook instead of doing any math, or
adding in any extra string and expression functions just for that.
You also have to think about time... Not a point in time, but a length
of time. A common response to the question How long is that going to
take? will not be 90 min, or even 1.5 hours, it will be 1 hour and 30
minutes, or at least 1 hour 30 minutes. So that in itself would be a
nice reason to support multiple values. In addition to historical data
which still uses old numeric formats.
I was actually thinking of allowing separators for separating data
(space, comma, etc...) and an Allows format built in parameter for
special cases.
So for the # ft #in you'd allow space, for the # ft, #in you'd allow
comma, and even for 1 hour and 30 minutes you could allow 'and' as a
separator.
Then you would use [[Allows format::#'#]] and it would recognize
something with the regex /(\d+)(')(\d+)()/ where every odd is a digit,
and every even equivalent is something it checks the list of available
units for.
Though I suppose I should come up with a better thought so that it could
support things like ##:## and recognize it as hours:minutes.
~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)
S Page wrote:
DanTMan wrote:
Has anyone attempted to get SMW to support special types of number
notation, basically where multiple numbers of different units are
written out.
Basically such as [2ft 5in] or the classic format [2'5]
Nobody as far as I know.
You could write a custom datavalue that parses it, similar to
SMW_DV_GeoCoords.php. Trying to add it into SMW_DV_Linear.php to give
you unit conversion would be challenging, as SMWLinearValue just
relies on SMWNumberValue's parsing. Maybe you'd parse once to get
(value=2, unit=ft 5 in), then notice that convertToMainUnit() fails,
so parse again to see if there's a second value.
It would be a lot easier to support multiple units only in display,
something like
[[display units::%dft %.2fin, meters, km]]
and you'd beef up SMWLinearValue-makeConversionValues() to parse this
sprintf-like format.
FWIW the GNU units program http://www.gnu.org/software/units/ , the
most impressive conversion program I've found, doesn't attempt
multiple units, nor does Java JSR-275 (units). Come on United States,
Liberia, and Myanmar, get with metrication ;-)
--
=S Page
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
[SMW-devel] Creating a real Enumeration
I was thinking of creating an actual enumeration type. Currently enumerations are done with a String type alias, and just using [[Allows value::...]]. However, afaik there is no way to add aliases (Inf to Infinite, etc...), and it also doesn't support recognizing similar things (like when someone inputs male instead of Male, just with different case). So I was thinking of either making an actual Enumeration, or perhaps creating an InsensitveString type, and also extending Allows value or adding in another builtin to support aliases. -- ~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) - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] [PATCH] Support LIKE in queries
^_^ 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::=value]] LTEQ: [[property::=value]] NWILD: [[property::!%value]] (Negated wild card) REGEX: [[property::~value]] or perhaps [[property::~/value/i]] (/ could of course be replaced with !, [], etc... any valid in preg. NGT: [[property::#value]] (Natural order greater than) NLT: [[property::#value]] (Natural order less than) NGTEQ: [[property::#=value]] (Natural order greater than or equal to) NLTEQ: [[property::#=value]] (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 =, 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. ~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ötzsch 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: = Equals Greater than = Greater than or equal to Less than or equal to ! Not * Multi-character match ? Single-character match ~ regex As a note: = is not available in parser function #ask, since it has a special meaning as parameter assignment, as e.g. in format=table. The query is distinguished from the other parameters and print requests in #ask since it has no = 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::[EMAIL PROTECTED] or [[prop::comp#match]]. So for a not [[Has value::[EMAIL PROTECTED] 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[=], NOT/NEQ/[!] (!= could be thought of),LT
Re: [SMW-devel] [PATCH] Support LIKE in queries
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.)
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:
= Equals
Greater than
= Greater than or equal to
Less than or equal to
! Not
* Multi-character match
? Single-character match
~ regex
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. @ 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::[EMAIL PROTECTED] or [[prop::comp#match]]. So for a not [[Has
value::[EMAIL PROTECTED] or [[Has value::!#Value]].
I'm probably droning on now... But what about finding a good separator
and allowing textual names ie: EQ[=], NOT/NEQ/[!] (!= could be thought
of),LT[], GT[], REGEX(P)[~], LIKE[%_], wildcard[*?], etc...
There also is the possibility of instead of a separator, using brackets
to encompass a comparator. I can hardly think of many places which would
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, but
{} is only used in multiples as a template or variable bit but never has
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.
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ötzsch 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 similar 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ötzsch [EMAIL PROTECTED] wrote:
Thanks. I have applied the patch, and added a way of configuring this
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 would 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
