The Cache store wrapper takes a master store and a caching store, caches data from the master into the caching store for faster lookup. Normally one would use a memory store for the caching store and a server store like JsonRest for the master store.
Parameter | Type | Description |
---|---|---|
masterStore | undefined | This is the authoritative store, all uncached requests or non-safe requests will be made against this store. |
cachingStore | undefined | This is the caching store that will be used to store responses for quick access. Typically this should be a local store. |
options | Object |
Optional These are additional options for how caching is handled. |
See the dojo/store/Cache reference documentation for more information.
var master = new Memory(data); var cacher = new Memory(); var store = new Cache(master, cacher);
If the store has a single primary key, this indicates the property to use as the identity property. The values of this property should be unique.
If the store can be queried locally (on the client side in JS), this defines the query engine to use for querying the data store. This takes a query and query options and returns a function that can execute the provided query on a JavaScript array. The queryEngine may be replace to provide more sophisticated querying capabilities. For example:
var query = store.queryEngine({foo:"bar"}, {count:10}); query(someArray) -> filtered array
The returned query function may have a "matches" property that can be
used to determine if an object matches the query. For example:
query.matches({id:"some-object", foo:"bar"}) -> true query.matches({id:"some-object", foo:"something else"}) -> false
Add the given object to the store.
Parameter | Type | Description |
---|---|---|
object | Object | The object to add to the store. |
directives | dojo/store/api/Store.AddOptions |
Optional Any additional parameters needed to describe how the add should be performed. |
The new id for the object.
Remove the object with the given id from the underlying caching store.
Parameter | Type | Description |
---|---|---|
id | Number | The identifier for the object in question. |
Get the object with the specific id.
Parameter | Type | Description |
---|---|---|
id | Number | The identifier for the object in question. |
directives | Object |
Optional Any additional parameters needed to describe how the get should be performed. |
A QueryResults object.
Retrieves the children of an object.
Parameter | Type | Description |
---|---|---|
parent | Object | The object to find the children of. |
options | dojo/store/api/Store.QueryOptions |
Optional Additional options to apply to the retrieval of the children. |
A result set of the children of the parent object.
Returns an object's identity
Parameter | Type | Description |
---|---|---|
object | Object | The object to get the identity from |
Returns any metadata about the object. This may include attribution, cache directives, history, or version information.
Parameter | Type | Description |
---|---|---|
object | Object | The object to return metadata for. |
An object containing metadata.
Put the object into the store (similar to an HTTP PUT).
Parameter | Type | Description |
---|---|---|
object | Object | The object to put to the store. |
directives | dojo/store/api/Store.PutDirectives |
Optional Any additional parameters needed to describe how the put should be performed. |
The new id for the object.
Query the underlying master store and cache any results.
Parameter | Type | Description |
---|---|---|
query | Object | String | The object or string containing query information. Dependent on the query engine used. |
directives | dojo/store/api/Store.QueryOptions |
Optional An optional keyword arguments object with additional parameters describing the query. |
A QueryResults object that can be used to iterate over.
Remove the object with the specific id.
Parameter | Type | Description |
---|---|---|
id | Number | The identifier for the object in question. |
Starts a new transaction. Note that a store user might not call transaction() prior to using put, delete, etc. in which case these operations effectively could be thought of as "auto-commit" style actions.
This represents the new current transaction.