Re: [SMW-devel] [PATCH] Support LIKE in queries

2007-12-27 Thread Markus Krötzsch
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 !

Re: [SMW-devel] Patch - displaying thumbnails for image results in inline queries

2007-12-27 Thread Markus Krötzsch
On Donnerstag, 20. Dezember 2007, Yaron Koren wrote: > Hi, > > On a project I'm working on, a table generated by an #ask function lists > image pages in one of the columns, and I wanted to display thumbnails, > instead of image file names, in that column. Then I had the thought that > inline querie

Re: [SMW-devel] SMW performance

2007-12-27 Thread Wang, Alex (NIH/CIT) [E]
Forget my previous post. The problem goes away when I removed one template. It seems the performance issue is related to the application instead of the database. From: Wang, Alex (NIH/CIT) [E] Sent: Thursday, December 27, 2007 4:46 PM To: semediawiki-devel@lis

[SMW-devel] SMW performance

2007-12-27 Thread Wang, Alex (NIH/CIT) [E]
It is very slow (30 seconds) to open any pages including "Main Page". Checking the processes in mysqld found the following sql statements for each page respectively. I guess `prop11`, `prop8`, `cats6` are temporary tables, which make it hard to tune these statements. Does anyone know if these

Re: [SMW-devel] {{#ask}}

2007-12-27 Thread cnit
> (2) Query answering is done without any caching, and this is clearly a > problem. While inline queries are computed only once and stored in the parser > cache afterwards, Special:Ask has no caching facility at all. This needs to > change in the future. Targetted cache invalidation might still be

Re: [SMW-devel] [Semediawiki-user] New data type for dates

2007-12-27 Thread cnit
> Now first of all thank you very much for this nice contribution! We are aware > of the limitations of Type:Date and would very much like to extend it > considerably in future versions (after 1.0, since it is a lot of work). The > goal would then be to have one single time datatype that can handle