Opened 11 years ago

Closed 10 years ago

#7527 closed defect (invalid)

Adding and removing items in a grid.

Reported by: yaz_k83 Owned by: Jared Jurkiewicz
Priority: high Milestone: 1.3
Component: Data Version: 1.1.1
Keywords: Add, remove, grid Cc: yazad3@…, Jared Jurkiewicz
Blocked By: Blocking:

Description

Hi,

We were trying to develop a page with 2 grids... the functionality was to be able to add the rows of the first grid into the second... and the user has the liberty to remove the added rows from the second grid.

We faced a problem when:

  1. The user adds a row from grid one to grid 2.
  2. The user removes the row from the second grid.
  3. The user tries to add back the same row.

(This is when we get an assertion error).

On inspection it was a problem with 2 assertions made in the ItemFileWriteStore?.js.

_ 102 : this._assert(typeof this._pending._newItems[newIdentity] === "undefined");

103 : this._assert(typeof this._pending._deletedItems[newIdentity] === "undefined"); _

Commenting the above lines makes the code work fine.

The problem is that the value identity field is being used as the index of the array of new values which certainly is wrong.

I request you to to fix this issue at your earliest. Sorry at this point I don't have a html proto to share.

Regards, Yazad Khambata

Attachments (4)

addRemoveData.txt (1.1 KB) - added by yaz_k83 11 years ago.
addRemoveGridTest.htm (4.2 KB) - added by yaz_k83 11 years ago.
addRemoveData_withoutIdentifier.txt (1.0 KB) - added by yaz_k83 11 years ago.
This file does not use identifier…
addRemoveGridTest_withoutIdentifier.htm (4.2 KB) - added by yaz_k83 11 years ago.
This file does not use identifier.

Download all attachments as: .zip

Change History (14)

comment:1 Changed 11 years ago by Bryan Forbes

Priority: highestnormal
severity: blockernormal

In order to diagnose this problem, I need a test case. Until then, I'm reducing the priority and severity.

comment:2 Changed 11 years ago by Nathan Toone

Resolution: invalid
Status: newclosed

This is not a bug - it is how the ItemFileWriteStore? is intended to behave. When adding/removing items from the store (which you are doing by adding/removing rows in the grid) you must ensure that each has a unique identifier. Your store can either define an identifier - or it can use the index of the row in the array (which is the default if you don't specify an identifier).

Another thing that can help is that you need to make sure and save your stores in between adding and removing an item with the same identity that has already been deleted.

Please read the documentation on ItemFileWriteStore? for more details.

comment:3 Changed 11 years ago by yaz_k83

Resolution: invalid
Status: closedreopened

I have attached 2 files to replicate the issue and am reopening the ticket.... Please read my first post where I am pointing to specific "assertions" in the ItemFileWriteSTore.

I understand the significance of identity in ItemFileWriteStore? but when a field is removed from the model why cant i add it back?

Regards, Yazad Khambata

comment:4 in reply to:  1 Changed 11 years ago by yaz_k83

Hi,

I have attached the files and reopened the ticket. In case this defect is accepted by you I request you to increase the priority and severity to what it was set originally since I unable to do so now.

Regards, Yazad Khambata

Changed 11 years ago by yaz_k83

Attachment: addRemoveData.txt added

Changed 11 years ago by yaz_k83

Attachment: addRemoveGridTest.htm added

Changed 11 years ago by yaz_k83

This file does not use identifier...

Changed 11 years ago by yaz_k83

This file does not use identifier.

comment:5 in reply to:  2 Changed 11 years ago by yaz_k83

Dear Toonetown,

Based on what you said in the post I have added 2 more files (the ones with the _withoutIdentifier). Surprisingly the defect is NOT replicated in these files... This is all the more a reason for reconsidering the assertion... The minute the identifier is anything other than the row index the assertion fails.

ItemFileWriteStore?.js _ 102 : this._assert(typeof this._pending._newItems[newIdentity] === "undefined");

103 : this._assert(typeof this._pending._deletedItems[newIdentity] === "undefined"); _

In the above code "newIdentity" CANNOT be used as index of an array if the identifier is NOT the default row index.

Regards, Yazad Khambata

comment:6 Changed 11 years ago by Nathan Toone

Cc: Jared Jurkiewicz added
Component: DojoX GridData

I think that jared might better be able to explain. However, as I understand it, if you do *NOT* specify an identifier, then the store will use a unique number for you (which is why you are not getting the assertion at that point).

In any case, this is a dojo.data issue - not a grid issue (I think).

comment:7 Changed 11 years ago by yaz_k83

Thank you Toonetown, Your prompt response is highly appreciated... The reason why I agree it may NOT be a grid issue... It is in fact a ItemFileWriteStore? issue.

The assertion flatly assumes that the identifier IS THE row index, which is NOT true in all cases.

Like in my case I have a date/string as identifier.

Regards, Yazad Khambata

comment:8 Changed 11 years ago by bill

Milestone: 1.21.3

comment:9 Changed 10 years ago by Bryan Forbes

Owner: changed from Bryan Forbes to Jared Jurkiewicz
Status: reopenednew

comment:10 Changed 10 years ago by Jared Jurkiewicz

Resolution: invalid
Status: newclosed

deletedItems is an associative map not an array. That means you can use both strings and numbers as the entry. The lookup and assertion is valid.

Secondly, its a misuse of IFWS to remove an item and then try to insert it back in without doing a 'save'. You can't reuse an identity until you save the state and clear out any 'pending state changes.

So, your usage scenario is wrong for IFWS. If you remove an item from a grid and then try to insert it back (all pointing to the same IFWS), you need to do a save before you insert to clear all pending state.

The reason it works for a dataset where you didn't specify an identifier attribute is that IF*S auto-generates one for you, which is an incrementing number and as such never collides (always unique and *not* a visible attribute of the store item).

This isn't a an IFWS bug, its how it was designed. Identities are supposed to be unique. When you specify an identifier, you are in charge of making sure it remains unique. Without doing a save and committing the changes (thus clearing out a reserved identifier for a deleted item), you cannot reuse an identifier of a 'deleted' item because that identifier is still in use. It is what is used to track state changes.

So ...

If you want to reinsert an item and you have specified identifiers for IFWS (meaning you control them), then you need to do a save before you insert it back into the store

Note: See TracTickets for help on using tickets.