Last modified: 2010-05-27 10:49:31 UTC
Overview: Create a Concept:Recursive_concept that contains a line: {{#concept:Recursive_concept}} Actual Results: The wiki crashes and becomes inaccessible whenever you access the concept page directly or in an ask query. Expected Results: As a fast fix, the recursive call should be ignored and maybe there could be a info text saying that there was an attempt to run an infinite-loop. Additional Information: The recursive concepts could be a new feature of SMW and there should also be possible to use parser functions inside concepts to have stop conditions for recursive querying.
UPDATE: Use case: I have a Folder/Item structure where a folder can contain subfolders and subitems. I need to use for example Semantic Drilldown to query all items recursively from a given parent folder. If Semantic Drilldown were to support concepts, and the concepts were implemented recursively, then this use case would be easy to implement. We could also have various conditions that would stop recursion at some level or exclude some items: say, all items that have a [[flag::true]] should be included and the rest ignored.
Support for recursive concepts might be implementable, but is the topic of another feature request (Bug 15316). Regarding your problem, I do suspect that the issue is not actually the recursion. The concept description {{#concept:Recursive_concept}} that you specify is simply invalid. The parser function #concept expects a query string that looks like the one used for #ask. So it would be {{#concept:[[Concept:Recursive_concept]]}}. But concepts are not allowed on concept pages in SMW's normal configuration (since they are not supported there anyway). So what happens in either case is that SMW does not find a valid query condition and is left with a query without conditions. This query returns all pages, and may thus require more resources than your normal query (although only 200 results are actually displayed). This can cause the page becoming inaccessible if your server does not have enough memory for such large queries. To work around this, manually type "?action=edit" after the page URL to change its contents again. I change the bug description accordingly, and we will still look at the error behaviour of concepts. It is not really useful to have queries for all pages, so maybe we will just catch this case on another level to avoid such problems being caused accidentally.
You're right, I slipped a little mistake there and didn't write correctly the concept description. It should have been {{#concept:[[Concept:Recursive_concept]]}}. About recursion, please check the email I sent you a few days ago - I tried to describe a few possibilities for implementation and I don't know which sounds better/or is more doable. Thanks.
Back to this problem (making a page inaccessible): I noticed that the situation where a concept contains no valid query condition whatsoever (this is what happens when trying to use recursive concepts) caused an error in query processing. This was digested by PHP without giving up the processing completely on my machine, but maybe it still was the cause for the empty (inaccessible) page on your site. Besides this, I do not find that the query for all pages consumes so many resources that it actually causes troubles on my site. If you prefer to not have (partial) queries executed on a best effort basis when errors occurred in their processing, then you can set the SMW setting $smwgIgnoreQueryErrors = false; to prevent this. This was not working for concept-based errors until very recently. These recent changes should resolve this issue.
That would be just fine - I'll use the SMW setting you mentioned. Regarding the recursion issue on parent-child semantic structures(like folders with subfolders and items or FOAF structures) what do you think? I'm sorry for asking about the email I've sent for the recursion thing here but it's just that I'm not sure it was successfully sent. If possible and you have a minute to spare, I kindly ask you to take a look at it just for a short answer. Thanks.
