Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#8412 closed defect (worksforme)

FileItemWriteStore references serialization error

Reported by: rsaccon Owned by: Jared Jurkiewicz
Priority: high Milestone: tbd
Component: Data Version: 1.2.3
Keywords: dojo, FileItemWriteStore, serialization Cc:
Blocked By: Blocking:


If I delete an item which contains references and if I _dumpReferenceMap() before and after the deleteItem call, I see that the references actually have been deleted. But when I serialize with _getNewFileContentString(), which is internally called when saving the store, then the references appear again, in the serialized string.

I am usung dojo trunk.

Attachments (1)

working_Example.html (1.4 KB) - added by Jared Jurkiewicz 10 years ago.
Example showing it working fine.

Download all attachments as: .zip

Change History (7)

comment:1 Changed 10 years ago by bill

Component: GeneralData
Owner: changed from anonymous to Jared Jurkiewicz

comment:2 Changed 10 years ago by Jared Jurkiewicz

The reference map itself shouldn't be getting serialized (As it gets constructed on parse), so thats ... interesting. I'll take a look.

Changed 10 years ago by Jared Jurkiewicz

Attachment: working_Example.html added

Example showing it working fine.

comment:3 Changed 10 years ago by Jared Jurkiewicz

I can't reproduce this issue. I get what I expected to get when I call a delete on an item with references, then call store._getNewFileContentString(), I don't see the references.

See output: Reference map before delete: Item: [bill] is referenced by: {"bob":{"children":true},"sue":{"siblings":true}} Item: [sue] is referenced by: {"bob":{"children":true},"bill":{"siblings":true}}

Reference map after delete: Item: [bill] is referenced by: {"sue":{"siblings":true}} Item: [sue] is referenced by: {"bill":{"siblings":true}}

String before save: { "identifier": "name", "items": [ { "name": "bill", "siblings": { "_reference": "sue" } }, { "name": "sue", "siblings": { "_reference": "bill" } } ] }

String after save: { "identifier": "name", "items": [ { "name": "bill", "siblings": { "_reference": "sue" } }, { "name": "sue", "siblings": { "_reference": "bill" } } ] }

Reference map after save: Item: [bill] is referenced by: {"sue":{"siblings":true}} Item: [sue] is referenced by: {"bill":{"siblings":true}}

Using attached test file: working_Example.html.

Can you provide a testcase where it fails?

comment:4 Changed 10 years ago by Jared Jurkiewicz

The only thing I can fathom is that you're misusing the store somehow. My initial guess is:

Using the same data structure across multiple stores (and thus getting piles of extra things stuck on the items. Eg, something like:

var data = {

identifier: "name", items: [

{name: "bob"}, {name: "sue"}, {name: "jill"}



This is wrong var store1 = new{data: data}); var store2 = new{data: data});

The store processes a data object and attaches on internal values to that object. If you reuse the same data object one across multiple stores, it will be confused by this because each instance will have attached on its stuff and not know about the other stores junk. You have to make copies if you intend to reuse the same object.

Correct: var store1 = new{data: dojo.fromJson(dojo.toJson(data))}); var store2 = new{data: dojo.fromJson(dojo.toJson(data))});

That will create unique copies of the data structure and avoid cross-contamination.

If this is not the cause of your issue, then I will need you to provide a testcase that demonstrates the problem, as my testcase does not exhibit such behaviors.

comment:5 Changed 10 years ago by Jared Jurkiewicz

Resolution: worksforme
Status: newclosed

Marking as worksforme. If you can provide a testcase where this fails, please do so and reopen. Thanks.

comment:6 Changed 10 years ago by rsaccon

My interpretation of the test results was wrong, otherwise everything is fine with the FileItemWriteStore?, sorry for the noise.

Note: See TracTickets for help on using tickets.