Between 1.7 and 1.8 some changes happen in how a container is being handled and while a fatal should not happen try not to use a named identifier and instead use (omitting the named "Test" identifier):

{{#subobject:

}}

{{#subobject:

}}

my.think wrote:

That way I will get two different subobjects - what if I want to store these values in the same subobject? It makes the template structure easier, and there's not exactly a good way to fill optional values in #subobjects. The other way is conditionally leaving the value out:

and using one giant call to #subobject, which makes the template logic so much more complex.

This is all working as intended in the way that multiple calls to #subobject with the same identifier will add data to the subobject, just like multiple calls to #set will add to the properties of the page, except for when a record is called anywhere but in the first call to #subobject, which causes a fatal error.

Shouldn't changing the order of SMW calls in the page cause identical results?

From my example above, I want to create a subobject PAGENAME#Test with the following data, and the records should be added in subsequent #subobject calls from a template:

• TextProperty: Test & Test2
• RecordProperty: Testing;123 & TestingAgain;234 or more, up to 4 times.

For context: I'm storing recipes, and every record contains an ingredient name + its amount. There can be multiple recipes for a single page, so I'm storing a subobject for each recipe instead of using the page directly.

I do understand your scenario but as of now I don't have a fix for this problem.

The problem is that the record type is being handled has a subobject itself (this was the change in 1.8 I think) which means that you are storing a subobject within a subobject and when using the same identifier creates the described unfortunate situation.

The "record type" subobject uses the "real" subobject as a SMWDIWikiPage reference (see below) and this is where the subSemanticData issue occurs.

{{#subobject: Test

}}

protected 'mSubject' =>
object(SMWDIWikiPage)[243]

protected 'm_dbkey' => string 'Subobject_record_type' (length=21)
protected 'm_namespace' => int 0
protected 'm_interwiki' => string '' (length=0)
protected 'm_subobjectname' => string 'Test' (length=4)

protected 'subSemanticData' =>
array (size=0)

empty

{{#subobject: Test

}}

protected 'mSubject' =>

object(SMWDIWikiPage)[290]
  protected 'm_dbkey' => string 'Subobject_record_type' (length=21)
  protected 'm_namespace' => int 0
  protected 'm_interwiki' => string '' (length=0)
  protected 'm_subobjectname' => string 'Test' (length=4)

protected 'subSemanticData' =>

array (size=1)
  '_d2f07a28343b60fc1a29f127e1820034' =>
    object(SMWContainerSemanticData)[300]

(In reply to comment #3)

The "record type" subobject uses the "real" subobject as a SMWDIWikiPage
reference (see below) and this is where the subSemanticData issue occurs.

After further investigation, the exception is raised because addSubSemanticData() checks for the "subDataAllowed" property if it set true or false.

addSubSemanticData() is called recursively during the process of adding container data and during that process $semanticData->subDataAllowed = false; is set which inevitably causes the exception during the recursive call.

I can't say for sure why $semanticData->subDataAllowed = false is set at this point, maybe it is to avoid circular reference within subobject.

The documentation points to subDataAllowed being an "Internal flag that indicates if this semantic data will accept subdata. Semantic data objects that are subdata already do not allow (second level) subdata to be added."

It could be that because the record type is a subobject itself and by trying to add the same record (which is what happen when you assign RecordProperty = Testing;123 to the second caller which in fact is the same subobject) by trying to resolve the container data subDataAllowed property is set false which is causing the exception.

(In reply to comment #4)

The documentation points to subDataAllowed being an "Internal flag that
indicates if this semantic data will accept subdata. Semantic data objects
that
are subdata already do not allow (second level) subdata to be added."

It could be that because the record type is a subobject itself and by trying
to
add the same record (which is what happen when you assign RecordProperty =
Testing;123 to the second caller which in fact is the same subobject) by
trying
to resolve the container data subDataAllowed property is set false which is
causing the exception.

Yes, this is right. Though I don't remember why adding subobjects to subobjects was disabled like this. Markus would know :)

my.think wrote:

This is when the change was added:
https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/extensions/SemanticMediaWiki.git;a=commitdiff;h=abbd2693ee3dcafabb5102b3c3c4f3a198bd9885

Now, I have no idea about the internal operations of SMW, but from an outside perspective, in 1.7, I never had a problem with records in subobjects, and found it only natural to use them just like any other type in subobjects.

Also: why can I add a record in the first call to #subobject, but not in later calls, even if there was no record added on the first call? It seems to me that adding a record to a "top-level" subobject should be allowed anyways.

In any case, can we make this fail more gracefully than with an exception? It's rather disturbing for the edit process, because it even triggers on preview. Also, most wikis will not show exception error texts/backtraces to the user, but rather a generic "Internal wiki error" message.

(In reply to comment #6)

This is when the change was added:
https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/extensions/
SemanticMediaWiki.git;a=commitdiff;h=abbd2693ee3dcafabb5102b3c3c4f3a198bd9885

Nice job finding this commit but the commit message also states that "This fixes some problems with nested subdata (mainly created by using Record properties within #subobject).".

Unless it is clear what those problems were, the current exception was placed their on purpose and I'm inclined not to change this behaviour without further knowledge as to why it was designed this way.

my.think wrote:

I didn't intend that it's changed without reasoning, I'm pretty sure there is a reason. I looked around for any bug reports mentioning problems but couldn't find any.

In case this isn't fixed/working as intended, I can surely find another workaround.

As described in comment 4/5, it is the intended design. The record type itself is represented internally as subobject and therefore and not be added recursively to another subobject.

See pull request 1300.