I am not sure if my approach in Sciter/TIScript for data persistence
is applicable
to JS engines used in browsers... but I'll try to explain it with the
hope that its
idea can be useful at least to some extent.
The whole data persistence in TIScript [1,2] is defined by two objects
[classes]:
- Storage - the data storage, and
- Storage.Index - index, persistable ordered key/value map.
Each Storage instance has property named `root`.
Any object that is reachable from this root is persistent - will
survive VM shutdown.
Example:
var storage = ...;
storage.root = {
one: 1,
two: [ 1,2,3 ],
three: { a:"A", b: "B", c: "C" }
};
this will initialize persistent storage by the structure above.
After this, in current or next script session, access to
the storage.root will return that object. From that object
all its descendants are reachable as usual.
Physical commit (write) of objects to storage happens on either
a) GC cycle or b) on explicit storage.commit() call or on c) VM shutdown.
Objects from storage are loaded on demand - when they accessed.
Therefore the storage provides transparent (for the JS programmer) set of
operations. Data access to persistent objects is made exactly in the same way
as to other objects in script heap.
The only limitation: not all objects in script heap can be persistent this way.
Only "JSON" subset (array,object, numeric, bool, string and null),
Dates and Indexes.
For obvious reasons.
This persistence schema uses minimum number of abstractions and
has full set of operations needed for accessing and storing structured
data. At least it is easier than http://www.w3.org/TR/IndexedDB/ :)
My pardon if all above is not exactly in mainstream.
Persistence in TIScript is based on Konstantin Knizhnik's DyBase [3].
[1] TIScript high level definition:
http://www.codeproject.com/Articles/33662/TIScript-language-a-gentle-extension-of-JavaScript
[2] TIScript source code: https://code.google.com/p/tiscript/
[3] DyBase http://www.garret.ru/dybase.html
--
Andrew Fedoniouk.
http://terrainformatica.com