PrivateStorage can fail to persist items


Steps to reproduce;

  1. Assuming two users, test1, test2, run the following code:

  2. Examine the contents of ofPubSubItem;

Expected results

  • The database shows two rows of data, one for user test1 and one for test2.

Actual results

  • The database shows one row of data, test2 only.




Greg Thomas
November 19, 2018, 9:57 AM

After some reflection, I think the correct answer is option b) above. I think the intent of the code is to avoid persisting PubSubItems that are already out of date. - and as such an item should be identified by it's complete identifier - i.e. serviceID + nodeID + id. Looking in to a PR now ...

Greg Thomas
November 16, 2018, 4:48 PM

OK, so the itemKey is made up of a concatenation of nodeID (blank in this sample) and id ("current"). 


(a) The id for PrivateStorage items needs to be more unique (e.g. the serviceID) (i.e. this only affects PrivateStorage items), or

(b) The itemKey should be made up of a concatenation of serviceID + nodeID + id (which matches the PK on the table) (i.e. this affects all PublishedItems).

I'm out of my depth, now. Perhaps someone else can chime in.

Daryl Herzmann
November 16, 2018, 4:43 PM

We are unsure if this issue is related to (corrupted bookmarks), but it hopefully is!

Greg Thomas
November 16, 2018, 4:36 PM

I believe the problem lies around line

The itemKey is ":current" - which is the same for both user1 and user2 - so the write for user1 is replaced by the one for user2 before it's saved to DB.

I'm currently unsure how to progress from here - I'm unsure of the intent behind this code area!


Your pinned fields
Click on the next to a field label to start pinning.


Greg Thomas


Greg Thomas