On Mon, Sep 17, 2012 at 7:55 PM, Yaron Koren <yaron@wikiworks.com> wrote:
Hi Markus,

I'm curious about what you wrote about adding custom tables for different properties - is there any documentation about it?


Strangely enough I came by this thread now.

There is some documentation about this but might be outdated a bit now (Markus did you change some code there too?). Anyway, you can get some idea from http://semantic-mediawiki.org/wiki/Fixed_properties of how to do this.

Note that all the data of such a property would then be stored and looked up from the new table. So all data from the older table the property was using has to be migrated to this one now.

As for the current code (at least in my extensions) that queries the SMW database tables directly, here's an explanation, in order from least to most challenging to "fix":

- Semantic Internal Objects stores its own data in the tables; as you note, this can probably be changed to use the new code for handlng subobjects.

- Semantic Forms does direct querying in order to autocomplete on substrings, in one function, SFAutocompleteAPI::getAllValuesForProperty(). You can see it here:


There's nothing in the SMW API that allows for substring matching the way SF does it (matching on the beginning of any word in the text); so something would have to be added.

- Semantic Drilldown does direct querying because it needs to generate temporary tables, in order to improve performance: every time Special:BrowseData is accessed, temporary tables are created that hold the set of pages that match the current selected set of filters, and then all the additional numbers and values on the pages are generated off of those temp tables. To get that functionality into SMW would require, I think, some serious additions to the code; and I don't know if it would be worth the effort.

(By the way, on that note - it would be great if SD could also handle cases where an RDF triplestore is used to hold SMW's data, but I think the lack of support for temporary tables in triplestores makes that impossible, regardless of whether it's SD or SMW doing the work of filtering. If anyone knows differently about that, though, please let me know.)


On Mon, Sep 17, 2012 at 6:06 AM, Markus Krötzsch <markus@semantic-mediawiki.org> wrote:
On 16/09/12 21:28, Yaron Koren wrote:
Hi James,

You make a valid point about the importance of SF and SD supporting
SQLStore3 in the near future. I plan to add support for the new database
structure to those extensions, as well as to Semantic Internal Objects,
which also has hardcoded calls to the SMW tables - ideally that can
happen in the next few weeks. I'm planning to do that by just adding
"if" statements to the relevant parts of the code, so that the SQL used
changes depending on which SQL store is being used. From my
understanding of the new DB structure, it shouldn't be that hard to do.

Yes and no. Regarding SIO you should be able to use SMW's API as discussed in earlier emails, so no table-related issues there. For SF, I am surprised that there is SQL-specific code at all. Some of the current store API functions are only provided for the use by SF, so if the kind of method that you need is not too hard to support, we could maybe do the same there.

SD will be more difficult to upgrade, I think (without knowing the details of its code). One thing to know about the new store is that it allows users to configure the tables that will be used. The individual table layout is quite similar to what we already have, but there can be a lot more (smaller) tables. In particular, some (important) properties can get their own tables.



By the way, some people might argue that these extensions shouldn't be
making direct SQL calls at all, which is a valid point; but the problem
is that, as far as I know, there's no other way at the moment to
retrieve (or, in SIO's case, set) the necessary data. If someone wants
to add such a capability to SMW for the use of one or more of these
extensions, I'd be glad to discuss it.


On Fri, Sep 14, 2012 at 10:45 AM, James HK <jamesin.hongkong.1@gmail.com
<mailto:jamesin.hongkong.1@gmail.com>> wrote:


    SMW 1.8beta has been released but some SMW core extensions (SF, SD
    etc.) using direct access to smw db tables that correspond to the
    SQLStore2 scheme[1]/[2] but are not compatible with the new SQLStore3

    In case of SF 2.5 one can use SMW 1.8/SQLStore2 but not SMW
    1.8/SQLStore3 (because of the SQLStore2 specific db selects).

    How to resolve this situation that in both cases (SQLStore2/SQLStore3)
    the integration works without interference?

    I think this question needs some attention before releasing SMW 1.8
    because when people start using the SQLStore3 in combination with core
    extensions like Semantic Forms or Semantic Drilldown problems will
    occur at the current implementation state.




    Got visibility?
    Most devs has no idea what their production app looks like.
    Find out how fast your code is with AppDynamics Lite.
    Semediawiki-devel mailing list
    <mailto:Semediawiki-devel@lists.sourceforge.net> ------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:

WikiWorks ˇ MediaWiki Consulting ˇ http://wikiworks.com

Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
Semediawiki-devel mailing list


Nischay Nahata