This issue persists with SMW 1.7.0 beta 1 Since I make good use of concept caches this is again a blocker from upgrading. Thus major → critical.

PHP Catchable fatal error: Argument 1 passed to SMWSQLStore2::getSemanticData() must be an instance of SMWDIWikiPage, instance of Title given, called in /.../extensions/SemanticMediaWiki/includes/storage/SMW_SQLStore2.php on line 199 and defined in /.../extensions/SemanticMediaWiki/includes/storage/SMW_SQLStore2.php on line 119
Catchable fatal error: Argument 1 passed to SMWSQLStore2::getSemanticData() must be an instance of SMWDIWikiPage, instance of Title given, called in /.../extensions/SemanticMediaWiki/includes/storage/SMW_SQLStore2.php on line 199 and defined in /.../extensions/SemanticMediaWiki/includes/storage/SMW_SQLStore2.php on line 119

I cannot tell why I get these error messages twice.

Will try to look at this soonish.

Can you get me an export of your concept NS? I can run the script w/o problems, but then again, I have no concepts on my local wiki.

Hmm, the concepts are rather simple like {{#concept: [[Category:Person]] [[PersonID::+]] [[Status::No]] }}. On the test wiki {{#concept: [[Category:Test]] }} already caused the problem.

Should be fixed by r105623.

The script now tries to create the caches for every page in namespace concept, but actually fails creating the cache for each page with the message "No concept description found". Checking with --status reveals that indeed no cache was created for each concept ("Not cached") [SMW 1.7.0 beta 2]

*sigh* I'll have another look at it then. Never used the script, so determining if it's doing what it's supposed to do is a bit hard.

No worries. Actually I am surprised that nobody else discovered this before. It is a feature that not only increases performance but offers much more flexibility for in-line queries. Concepts are my recommendation for implementors of SMW.

I have just tested this with rc1. The error is still persisting.

I know, don't have time to fix. Was in last rel, so does not block 1.7.

Ah ok, since this bug was listed as fixed in your e-mail of today I was already in happy expectations. It's true that it does not block 1.7 but I am still kinda stuck at 1.5.6. However that's not a problem as long as MW 1.17.x is supported. In case MW 1.18.x is supported by SMW 1.5.6 there is even more time. No worries.

desiree.gennaro wrote:

Has there been any update on this?

Still partly broken. It ought to work to some degree, at least more then in 1.6.x due to a fix by Markus and one by me. Will look at this further as soon as I have the time.

desiree.gennaro wrote:

Thank you for getting back to me on this.

Fixed in r108966. Concept descriptions had not been read properly from the store (unless used directly in querying when no cache was available).

If the cache update script still reports "No concept description found." for an existing concept page that has a proper concept description, then one should try editing that concept page to refresh the data. It might be that it simply did not make it into the SMW database after some upgrade or import.

Affirmative. I just tested r108966 from trunk and the concept are back and running. Great and thank you for that!

However, there is still one issue. In former versions of SMW the items included in the cache of the concept were displayed on the respective page of the concept. Currently nothing is shown.

• Bug 32718 has been marked as a duplicate of this bug. ***

(In reply to comment #16)

Affirmative. I just tested r108966 from trunk and the concept are back and
running. Great and thank you for that!

However, there is still one issue. In former versions of SMW the items included
in the cache of the concept were displayed on the respective page of the
concept. Currently nothing is shown.

I had also fixed this problem recently in r108971. Should work now.

I guess I was to fast testing it. :) Just tested this using r109572 with a positive result. Thank you for looking into this matter.

We use SMW 1.7.0.2 which means all those patches have been applied but some of those changes creates now problem when the query statement is a bit more complex.

For example a simple query like [1] works just fine (cache is created) but for a query like [2] the concept cache is empty but [2] worked before.

[1] {{#concept: [[Keyword::Japan]] }}

[2] {{#concept: [[Keyword::Japan]] OR [[Geographic Region::Japan]] OR [[Category:Japan]] OR [[Tag::~*Japan*]] }}

Another odd thing is that we created a new concept, and counted the objects within this concept showing 14503 elements.

After running SMW_conceptCache.php --create this particular concept now only shows to have exact 10000 elements and we can't get to the original 14503 (for now as it changes daily) furthermore we rely on the cache to be refreshed every hour.

In both cases we counted the elements with {{#ask: [[Concept:DMS]]|format=count}}

In all reported cases we use default settings for $smwgQConceptCaching,
$smwgQConceptCaching, and $smwgQConceptCaching.

This is somehow critical because using concepts allows to speed-up the query performance quite a bit but now knowing that not all elements are in the concept cache makes it a bit unreliable.

Dear MWJames,

you seem to be reporting at least two independent issues here that are not the original failure (which is fixed). If these problems persist, please open separate bug reports on each.

A few hints: the 10000 elements might be a limitation from the global query limit settings, since it happens to be the default value of $smwgQMaxLimit. This should be checked. The problems with "some complex concepts" needs more details: do the queries work when using #ask? can the problem be reproduced on the SMW sandbox? are only queries with certain feature combinations affected?