ItemFileReadStore - refetch from server

[guest]

Currently ItemFileReadStore will only fetch once from the server. This works well in most situations but many times it seems like people want to be able to tell the store to re-fetch data from the server. Usually the answer is "use QueryReadStore" - sometimes this is not appropriate or even possible (see #6071). Also, relying a a dojox component for your data store might make some people nervous as dojox implies "experimental" (even if QueryReadStore is quite stable).

From lurking on the forums I see this request periodically and it seems to frustrate a lot of people that this functionality is not possible and usually results in strange hacks, suck as creating a brand new QueryReadStore with the same URL as the original store and assigning it over your existing store. (e.g. mywidget.store = new_store)

[guest]

Please add josh@… to CC

[guest]

Yuck - I need to learn to type:

"suck as creating a brand new QueryReadStore?? with the same URL as the original store and assigning it over..."

should be:

"such as creating a brand new ItemFileReadStore?? with the same URL as the original store and assigning it over"

[guest]

Adding a Refresh command would be useful for the other Data Stores that fetch from Server URLs, like the XmlStore. Having a refresh() would be particularly be handy if I build a Client App that receives an Update notification from the Server (say, via Comet or some other polling mechanism), as I'd have an easier (and cleaner) mechanism to refresh my views with the latest data.

May I suggest adding this to the dojo.data.api.Read interface so all relevant data sources may benefit? Thanks!

-lalee

[jaredj]

There already is a function on the Read API that could be used for this putpose, the 'close' function. The description of that function is to close out any information remaining to a request (or to the store as a whole), and clear any internal caches, if any. So, realistically if close reset the internal state of the store back to its 'default' unloaded state, the next query to it would refetch the dataset from the server.

Though, with regard to the comment about update notification to refresh views ... that is the purpose of the Notification API. That allows the datastore impl, should it chose to implement it, a mechanism by which events such as new item creation, deleted items, modified items, etc, can be detected. So that say a cometd event is occuring, that event can drive the onSet, onNew, onDelete callbacks and any widget listening to them would get the events abd be able to react according ly and update its views.

[bill]

Hmm, I thought close() was just supposed to clear information related to the request (ie, the current fetch() call), not clear all cached data.

//	summary:
//		The close() method is intended for instructing the store to 'close' out 
//		any information associated with a particular request.

Seems dangerous for close() to erase everything that was downloaded from a URL... ComboBox could likely be calling close() on every keystroke, thus every new keystroke would cause an XHR, and it would grind to a halt.

[jaredj]

Look at the API again. Close is defined as:

close(request?).

Wher eif a request object is passed, it clears any cached data for that request, if no request objetc is set it clears all caches.

Which is effectively what the requester wants here. Flush the entire store cache and reload it.

[jaredj]

Patch to add in support for a clearOnClose option which flushes the store's internal cache fo the file and invalidates all open refs.

[jaredj]

Okay, option added. If the store is instantiated with a clearOnClose=true option and if it's loading from a url (not an in-memory dataset), then callong close() will flush the store and make it reload on the next fetch (cache flush). I made the default behavior of not flushing to keep it consistent with current expected behavior.

[jaredj]

Tested on:

Firefox 2.0.0.13

Safari 3.1

IE 6

Seamonkey 1.1.2

Opera 9.2

D.O.H: Rhino Runner:

---

GROUP "tests.data.readOnlyItemFileTestTemplates, with datastore dojo.data.ItemFileReadStore?" has 60 tests to run

---

GROUP "tests._base._loader.hostenv_rhino" has 1 test to run

---

GROUP "tests._base.declare" has 12 tests to run

---

GROUP "tests.i18n" has 9 tests to run

---

GROUP "tests.data.readOnlyItemFileTestTemplates, with datastore dojo.data.ItemFileWriteStore?" has 60 tests to run

---

GROUP "tests.data.utils" has 18 tests to run ...

---

GROUP "tests.data.ItemFileWriteStore?" has 36 tests to run

---

GROUP "tests.number" has 26 tests to run

---

...

I also cleaned up a bunch of jslint complaints in the write tests.

[jaredj]

(In [13532]) Added in support for reload when close() is called. fixes #6073 \!strict

[guest]

Thank you!

Josh

[bill]

I see you are referencing this ticket from http://dojocampus.org/content/2008/06/07/tree-server-fetch-on-node-expansion/.

Note that refreshing the store (IIUC) won't generate any notifications about changes in the data, and as such Tree won't update itself.

[trutwijd]

Replying to bill:

I see you are referencing this ticket from http://dojocampus.org/content/2008/06/07/tree-server-fetch-on-node-expansion/. Note that refreshing the store (IIUC) won't generate any notifications about changes in the data, and as such Tree won't update itself.

Bill, I looked at that article and I don't see the reference you are referring to?

Josh

[bill]

Hmm, yeah, I wrote down the wrong link. I think I was thinking of a forum post, but I'm not sure which one now.