Extension talk:SemanticQueryFormTool/Archive

New Storage Engine
Will there be support for the new Storage Engine and will there be a SVN Repository for this Extension? Because then I could use this Extension on WeCoWi. --DaSch 09:54, 8 September 2008 (UTC)
 * Hopefully yes at some stage. I'll try to keep this 'old storage engine compatible' version (with all its limitations) working with upcoming SMW versions but any new SQFT version would long-term anyway only make sense if its working with the new storage engine. Optimale 14:14, 8 September 2008 (UTC)

Dependent Selection
Is there a possibility to make several mselect-boxes dependend on each other? I'm trying to have a search form that incudes (among other options) a search for countries, regions and villages/cities. Now it would make great sense, if one couldn't choose first a land and then a region that's NOT in the land you chose in the first place, and in the next step one shouldn't be able to select a city that isn't in the selected region.

Thats my code so far, it's heavily stripped from your example:

Results: -

(I'm using SMV-properties because I want to have a boolean AND within that search, and afaik that wouldn't be possible with built-in wikipedia categories.) Is there a way to make the mselect boxes dependend somewhat like this: Country A -> Regions in Country A -> Cities/Villages in Region B in Country A

Thx,

Simon -- 12:05, 15 September 2008 (UTC)


 * Sorry for the late reply.


 * Yes you can do something like that with the help of javascript functions which are attached to a field of the form with the 'js=' parameter. I use it in a very similar way like you describe (except in a different context - if a certain chromosome is selected from the 'chromosome' select element the values in another select element for 'bands' change accordingly to allow only those bands to be selected which are located on the selected chromosome(s)). It's however not very elegant as the javascript has to contain hardcoded the information e.g. which country has which regions and which regions has which villages/cities in order to enable the script to disable (gray out) or remove certain elements from the select list resp. add/enable them 'on the fly'. One can do some quite advanced stuff with the right javascript but it's basically not different at all from what one can do to control elements of a normal form in a normal HTML site using javascript.


 * I use the addscript extension to add javascript functions which I store in a file on the server. But in theorie the whole script could be added directly as value to the 'js' parameter. So would might have the extra parameter  which calls the js function select_disable if the country is changed and which than can modify the region select element depending on the country value.


 * Btw to have 'any=(alle)' is not useful as SMW only understands '+' and '?' as wildcard characters for ask queries; this parameter is more useful to switch the display of '+' or '?' OFF e.g. in lists.


 * Optimale 17:01, 24 September 2008 (UTC)

Database error: table .cmw_smw_atts2 doesn't exist
Hi,

after installation, I get the following error:

A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was: (SQL query hidden) from within function "SQFTSMW::getSelectResult". MySQL returned error "1146: Table 'XXXX.cmw_smw_atts2' doesn't exist (localhost)". -Bernhard


 * Sorry about that. It was a bug - the database prefix was still hardcoded from the initial test :(
 * It should work now with version 0.1.2 on the ftp site
 * Optimale 22:54, 12 October 2008 (UTC)

Problems with MW1.13.2 and SQFT0.1.3
Hi all!

I don't know what I did, but the newest version of this extension (it's very helpful, many thanks for it!) does not work for me. I have a new installed MW1.13.2 and created two simple pages:
 * Page_one contains: Propertyname::one
 * Page_two contains: Propertyname::two

and a third:
 * Page_three contains:

but the option list of select tag is empty. I set the $wgShowSQLErrors and $wgDebugDumpSql variables to true in LocalSettings.php, but there are no error messages. The select tag appears nice. The page id's are there in prefix_smw_rels2 table. My SMW version is 1.3.

Can anybody help me? Thanks: Pipi69e 13:50, 30 October 2008 (UTC)

PS.: with type=article it works (it finds the correct property-page relations). Pipi69e 14:13, 30 October 2008 (UTC)

Pagename attribute causes MySQL error
Using pagename attribute causes the next error message: A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was: (SQL query hidden) from within function "SQFTSMW::getSelectResult". MySQL returned error "1064: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ')' at line 1 (localhost)".

The form works fine. Pipi69e 15:21, 30 October 2008 (UTC)


 * I think I finded an unnecessary closing bracket ')' on the end of 265. line of SemanticQueryFormTool/includes/SQFT_SQLFunctions.php. Deleting it solves the problem. Pipi69e 19:10, 30 October 2008 (UTC)


 * I just uploaded version 0.1.5 which hopefully resolves all bugs connected with retrieving property values of all types w/out specified namespace and/or pagename
 * Optimale 13:43, 6 November 2008 (UTC)

Update for SMW 1.4?
SQFT is currently (SemanticQueryFormTool_01_5.zip) not compatible with the newest SMW version. Would be cool if you could update it to make it work again :)
 * Version 0.1.6 is the last version compatible with <= SMW 1.3
 * Version 0.1.7 is the first version compatible with >= SMW 1.4
 * Optimale 10:51, 25 November 2008 (UTC)
 * Great, thanks :) --Pnagel 02:52, 26 November 2008 (UTC)

Simple #sask query for property of type Page doesn't work
Until now I always used SQFT's #sask for properties of type String. Now I wanted to use it with a property of type Page (explicitly specified in the Property page), but I only get a dropdown with a + in it, although there are >30 pages using the property. The query I tried was:

What am I doing wrong? --Pnagel 06:34, 9 January 2009 (UTC)
 * Sorry again for the late reply but somewho I don't seem to get the notification emails when this page is modified :(
 * Anyway it was a bug. I forgot in one place to replace the spaces of property names with underscores for the sql query. I corrected that now in version 0.1.9
 * Optimale 12:35, 26 January 2009 (UTC)

Example
This extension looks like it could be very useful. However, I tried to look at the example on malariapedia just now, but the site seems to be down. Do you know when that site might be available again or indeed if there is another place I could see a working example of this extension? Thanks Pnelnik 18:10, 17 February 2009 (UTC)
 * Unfortunately I don't really know of any other wiki where one could see the extension in action but the help.malariapedia.info site is up and should be accessible. It might be slow at times as it is a test site on an old server but the wiki will be moving to a new and hopefully faster hardware soon. So please try again to connect. Optimale 22:10, 17 February 2009 (UTC)
 * Maybe it's a result of the unusual port (14195) the webserver at mbi.molgen.mpg.de is running on - many company's firewalls or proxies will block outgoing traffic to this port. --Patrick Nagel 02:51, 18 February 2009 (UTC)

Thanks for the prompt response. I seem to be able to see the web-site today. Pnelnik 16:24, 18 February 2009 (UTC)

Combine two query conditions?
I'm currently mainly using #sask to generate tables with two columns, one containing property values, the other containing the number of times this value has been used. Now I'm wondering if it would be possible to get such a table that only contains the number of times a value has been used together with another condition, for example only matching pages that are in one specific category. Is it possible? --Patrick Nagel 08:00, 23 February 2009 (UTC)
 * Right now only those criteria can be used which are directly accessible within the SQL queries for the property values. These criteria are pagename and namespace. Using Category restrictions would mean to retrieve each page associated with a property value and do an extra DB search if that page is within a certain category or not. That would take too much time as the SQL queries are already time consuming if the number of properties is very high. So you can only restrict the result to matching pages within a list of pagenames or to pages within a list of namespaces. The other 'filter' action is after the retrieval purely based on the actual property values.
 * Well thinking of it there could be a 'trick' to restrict for Categories but I have so far never tested nor used it - so it might not work in practice:
 * In the 'article' mode a 'normal' #ask: query is used which can include Category: and it returns a list of linked pagenames. Most likely one has to somehow switch the linking off?
 * I'll see if I get it working and let you know. Optimale 13:44, 23 February 2009 (UTC)
 * I just made some modifications and from the next version it will be possible to feed a list pagenames to the pagename= parameter which is generated by a i.e. category specific #sask: type=article query e.g.:
 * but that could of course return a very long list of articles which might not work due to some limitation. But it works in principle. Optimale 16:25, 23 February 2009 (UTC)
 * but that could of course return a very long list of articles which might not work due to some limitation. But it works in principle. Optimale 16:25, 23 February 2009 (UTC)
 * but that could of course return a very long list of articles which might not work due to some limitation. But it works in principle. Optimale 16:25, 23 February 2009 (UTC)

Wanted links ?
Hi

I am using your great extension to display a list of values (keywords) from a property and provide links to pages for these keywords.

It is working fine except for one thing - all links are displayed the same way, whether the page exists or not.

Would you consider making link display aware of 'wanted pages' in a future version to make the display of links more consistent with the rest of the wiki ?

Regards

- Laurent Alquier
 * I assume you mean 'red' links to non-existing pages are blue? I haven't tested that so I have to look into it as I actually thought MW would take care of returning the correct link. Optimale 20:04, 28 March 2009 (UTC)


 * In the next version (0.2.1) links to non-existing wiki pages will show as 'red links'. Of course it makes only sense to add the 'link=' parameter (adding an internal link) if the property values are intended to be page titles, otherwise links will always be red.
 * It checks and tries to link to pages with the name of the property value in the 'Main' namespace. Only if the global variable '$sqftgAllowedNamespaces' is set, it checks through those namespaces first and uses the first namespace in which it finds a page with the name of the property value. If no page in any of those namespaces is found it shows a 'red link' to the page in the 'Main' namespace. Optimale 11:20, 30 March 2009 (UTC)

Only Property Values of Type 'Page' Returned After SMW Rebuild
Hi- I've discovered a very strange bug in SQFT (which is great! I've been using it extensively to enhance SMW.).

I have a large SMW installation. Versions: MW 1.13.3, PHP 5.2.4, mysql 5.0.51, SMW 1.4.2, SimpleForms 0.4.10.1, SQFT 0.2.0 SQFT was installed normally (no caching, no SQFT tables or indexes created).

'#sask' worked just fine when I installed it a month or so ago, and has worked well during that time. I could build unique lists of whatever semantic property in my system... Then, this week, my semantic tables got corrupted, so I used the recommended steps to rebuild everything from scratch using the SMW maintainance scripts:   After doing this, the SMW stuff all worked again just fine, as did many other SMW related extensions(results format most importantly)... but I noticed that #sask stopped working. This hosed a lot of pages. But, #sask did continue to work for Properties whose type was 'Page'? (where before the type of the property did not matter) If I switched some of the properties failing to return value lists from 'number/string/etc' to 'Page' suddenly #sask would work again?! And when switched back to 'number/string/date/etc' nothing would be returned. (note- I did make sure the database updates all succeeded, and touched LocalSettings.php between each change).
 * 1) delete old smw* tables.
 * 2) rebuild smw* tables.
 * 3) refresh smw* data for properties and types only.
 * 4) refresh smw* data for everything else.

Any help would be greatly appreciated. Thanks- User:iamh2o (Mar 28 2009)
 * As far as I know I use only the normal SMW tables to retrieve the data. I use SMW 1.4.2 (actually in Special:Version it says 1.5e-SVN), MW 1.14.0 and SQFT works for me for properties of type String and Number. I'll look into it on Monday. Do you have acces to the MySQL database, so you could enter some test queries directly? Optimale 20:39, 28 March 2009 (UTC)


 * Thanks for the quick reply! Yes, I have admin access on the box this wiki runs on, and would be happy to run test queries.  This is indeed odd: I didn't change SMW code at all, so the tables and data which were rebuilt should be exactly the same as when SQFT was working pre-schema/data refresh(and are as far as #ask query results I've QC'd go the SMW stuff all works fine).
 * I'll check back Monday. User:iamh2o (Mar 28 2009)
 * I sent you an email Optimale 16:39, 30 March 2009 (UTC)


 * The problem is resolved. It was caused by the fact that SQFT only transformed the first letter of a property name in an #ask query to uppercase when the property was of type Page but otherwise used the name as written in the query. As all property names are stored with the first letter in uppercase this caused problems in SQL queries. From SQFT version 0.2.1a all property names are treated like the Page properties and the first letters of property names in #sask queries are now case insensitive. Optimale 09:35, 2 April 2009 (UTC)