View Full Version : Localstorage does not save records with a given id

20 Jul 2015, 7:13 AM
Ext version tested:

Ext 6.0.0 GPL

Browser versions tested against:

Goggle Chrome


Localstorage does not save records with a given id and removes existing records when a record with the same id is added twice.

Steps to reproduce the problem:

Fiddle below

The result that was expected:

Record should be added one time to the store (since the next run would add the same record with the same given id) and remain in localstorage.

The result that occurs instead:

No record is added at all to localstorage.

See comments in the code for more details. When running the fiddle, watch localstorage and console output.

20 Jul 2015, 1:32 PM

In your example, you are explicitly setting the id, so the record is not considered a phantom. Because of this, the store doesn't know that a new record has been added, and since the record wasn't loaded via the proxy, it's not recognized as updated, either. So then, when sync is called, neither getNewRecords() nor getUpdatedRecords() return any results, so nothing is persisted via the proxy.

Is there a particular reason for setting the id directly, instead of using one of the identifiers?


21 Jul 2015, 3:18 AM
Hello Joel,

i see - and thank you for the information about how phantom records work.

The reason i used pre-defined ids is, that the final goal was to create a unique composite "id" key based on "url" and "username". This was to ensure that no record is added twice for the same url/username. (so the numeric id was only for testing).

The previous attempt was to define a function "isDuplicate()" and check a new record against the store before adding it.
However i disliked it, because i wanted the store to take care of it and not the outside code.
And i did not find a store event like "beforeadd", where i could have placed "isDuplicate()" inside the store.

So i came up with the idea of a unique composite "id" and thought i would let the store handle it and check for succuess/failure in the stores callback handler.

Maybe this is related?

Best regards