#7743 closed defect (wontfix)
deleted items remain in cache, new items not added
Reported by: | ben hockey | Owned by: | Kris Zyp |
---|---|---|---|
Priority: | high | Milestone: | 1.3 |
Component: | DojoX Data | Version: | 1.2beta |
Keywords: | Cc: | ||
Blocked By: | Blocking: |
Description
using:
dojox.data.ClientFilter dojox.data.JsonRestStore dojox.grid.DataGrid
in the grid definition - to make sorting work
queryOptions: {cache: true}
select a row to delete and then press a delete button hooked to code that uses the following mechanism to delete rows:
grid.removeSelectedRows(); store.save();
then click on a column header to sort and the deleted item appears in the grid again.
similar problems when trying to add a new item using
store.newItem(item)
and then sorting - new item disappears.
shouldn't the cache at least keep up with client side interaction?
Change History (8)
comment:1 Changed 13 years ago by
Owner: | changed from Jared Jurkiewicz to Kris Zyp |
---|
comment:2 Changed 13 years ago by
i have no query at all - not ever defined in my declaration of my store or grid. is a query necessary?
var store = new dojox.data.JsonRestStore({ target: storeTarget }); grid = new dojox.grid.DataGrid({ id: 'grid', store: store, structure: layout, queryOptions: {cache: true} }, document.createElement('div'));
comment:4 Changed 13 years ago by
Milestone: | tbd → 1.3 |
---|
I didn't change anything, but I will go ahead and close this if it is working for you now.
comment:5 Changed 13 years ago by
Resolution: | → wontfix |
---|---|
Status: | new → closed |
comment:6 Changed 11 years ago by
Resolution: | wontfix |
---|---|
Status: | closed → reopened |
I am having a similar issue, although in my case, the problem I have occurs after I call
store.newItem(item) store.save()
and then sort the grid by clicking the column header.
The new item appears correctly within the grid, however every grid page after the one with the new item displays a row that is identical to the new item row. The new item only exists in the store index once, so I am guessing the problem lies somewhere in either the ClientFilter? or DataGrid? paging code.
comment:7 Changed 9 years ago by
Resolution: | → wontfix |
---|---|
Status: | reopened → closed |
rpgdude, if this is still failing for you please open a new ticket and attach the test case using the attach file button.
comment:8 Changed 8 years ago by
Hello,
I am experiencing what I believe to be the same issue using dojo 1.7, ClientFilter?, EnhancedGrid? and JsonQueryRestStore?.
If I edit a cell in a row, and then sort on a column, I am seeing the row I edited as the first row in every page after page one. By page, I mean the default of 25 rowsPerPage. So, this edited row will appear in row 26 and row 51 and row 76 and so on. If I edit more than one row, each row is repeated just like the first. If I edit 3 rows they will reappear on lines 26, 27, 28 and lines 51, 52, 53, and so on. It appears these edited rows are overwriting rows that should actually be in those slots.
Is there a solution to this problem? I do not know how to begin troubleshooting this nor do I know how to submit a test case. We've put a lot of time into development using this EnhancedGrid? and JsonQueryRestStore? so we'd rather not have to try to switch to a different grid/store. Any help is greatly appreciated.
Are you using a string query or an object query (is the value of the query property a string or object)? If you are using an object query with name-value pairs as often used in Dojo Data, the ClientFilter? should work out of the box, but JsonRestStore? usually needs to be extended to convert the query to a URL. On the otherhand, if you are using a string query (which JsonRestStore? should understand), you will need to extend JsonRestStore? to properly implement isUpdateable and matchesQuery, so that the ClientFilter? knows what queries can be updated and which items belong in a query and which ones don't. Perhaps the documentation isn't clear enough on this.
There may arguable be a usability issue in that the ClientFilter? should maybe throw an error or not use cached requests when the query is not "updateable"; when the ClientFilter? doesn't know how to handle the query, as is the case by default with string queries. I am not sure about this, it may be too violent, not sure.