[Bug 47472] Fatal error for multiple instances of records in subobjects
https://bugzilla.wikimedia.org/show_bug.cgi?id=47472 MWJames changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #9 from MWJames --- 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. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 47472] Fatal error for multiple instances of records in subobjects
https://bugzilla.wikimedia.org/show_bug.cgi?id=47472 --- Comment #8 from Daniel Meyer --- 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. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 47472] Fatal error for multiple instances of records in subobjects
https://bugzilla.wikimedia.org/show_bug.cgi?id=47472 --- Comment #7 from MWJames --- (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. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 47472] Fatal error for multiple instances of records in subobjects
https://bugzilla.wikimedia.org/show_bug.cgi?id=47472 --- Comment #6 from Daniel Meyer --- 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. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 47472] Fatal error for multiple instances of records in subobjects
https://bugzilla.wikimedia.org/show_bug.cgi?id=47472 --- Comment #5 from Nischay Nahata --- (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 :) -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 47472] Fatal error for multiple instances of records in subobjects
https://bugzilla.wikimedia.org/show_bug.cgi?id=47472 --- Comment #4 from MWJames --- (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. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 47472] Fatal error for multiple instances of records in subobjects
https://bugzilla.wikimedia.org/show_bug.cgi?id=47472
--- Comment #3 from MWJames ---
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
| TextProperty = 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
| TextProperty = Test
| RecordProperty = Testing;123
}}
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]
--
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 47472] Fatal error for multiple instances of records in subobjects
https://bugzilla.wikimedia.org/show_bug.cgi?id=47472
--- Comment #2 from Daniel Meyer ---
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:
| Property = {{#if: {{{param|}}} | {{{param}}} }}
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.
--
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 47472] Fatal error for multiple instances of records in subobjects
https://bugzilla.wikimedia.org/show_bug.cgi?id=47472
--- Comment #1 from MWJames ---
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:
| TextProperty = Test
| RecordProperty = Testing;123
}}
{{#subobject:
| TextProperty = Test2
}}
--
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
