Class: LocalStaticDB

DefaultDB.LocalStaticDB()

This is a local storage implementation for those applications that do not supply their own in overriding the general DB methods given by the class DBClass nor by configuring a replacement for this class.

This class extends FilesAndRelays which will attempt to port stored object out to an external DB, connected via the message service relay.

One property of this storage class is that data is updated by the last writer. There is no mechanism for consensus exposed by this stack. Local copies can be inconsistent with remote entries. It is possible that an intermediary process can handle consistency, or a derived class might handle consistency. Part of the reason for this state of affairs is that the code here is provided for default usage of the Copious Transitions stack; it is not provided to solve a universal problem. Yet, it might provide some basic logic that can be used to interface with more universal architectures.

On the other hand, there is a pub/sub mechanism that may be configured. And, a subclass of this class may implement app_subscription_handler. One possibility for the implementation of that method may be to take in copies of known entries and recitfy the differences when they arive and also to put in new entries without much extra effort.

This implementation stores data, all entries, in a file and reloads it later. Large objects, those that can be sent through communication channels without relying on special streaming or P2P architectures, are stored in their own files, but a representation of the data, including the name of the file it is in, is stored in a PageableMemStoreElement element.

The handling of data persisted between runs is introduced by extending LocalStorageSerialization.

In this object storage, there is an assumption made about fields in the object. Object are expected to have or end up with about three different fields.

At least locally, the object will have a local identity or if not that some field indicating an owner of the object: _whokey Another id would be a wide area id (or univsersal id): _id. It is expected that objects anywhere would be stored with such an id. Then, the objects will have a hash (most likely a hash of the object data) stored in _key.

This stack expects that globally the two keys _id and _key will be part of the object. And, this stack will add _whokey locally.

However, if the object cannot be found by those two keys, then this stack may search the wider area for the object using the local key with the assumption that the local key is made up of some salient feature of the object. For example, it actaully might be the case that just one object is stored per owner, or perhaps _whokey and _key are the same universal hash. (It may be the case that all three fields are the same.)

Constructor

new LocalStaticDB()

Source:

Methods

application_hash_key(obj) → {string}

Parameters:
Name Type Description
obj object
Source:
Returns:
  • value in a field _key, which is expected to be the hash of the data
Type
string

del_key_value(whokey) → {boolean}

Clear out the local knowledge of this object. Requests the wider area to forget the object. Removes any files associated with the object.

The call to delete

Parameters:
Name Type Description
whokey string

named this to emphasize that this stack is usually used just for user objects.
Source:
Returns:
Type
boolean

flat_object(obj) → {string}

Stringify the object -- some implementations might want to use some other method to turn an object into a packed array.

Parameters:
Name Type Description
obj object
Source:
Returns:
  • the stringified object
Type
string

flat_object_size(obj) → {Number}

Add up all the fields values of an object that have a length field.

Parameters:
Name Type Description
obj object
Source:
Returns:
  • object size
Type
Number

(async) get_key_value(whokey) → {object}

Returns the object that can be found by the key.

Searches for the id of the data object by using a local identity, where the id mapped by the whokey refers to a universal wide area identity of the data.

If a local copy cannot be found it searches the wide area using the application defined field and the whokey as its value.

Otherwise, it finds one and tries to load its psme (PageableMemStoreElement). The object returned to the application will be stored with the psme. If the object is not large, it should be in the storage map, _storage_map. The method findOne will return the object from _storage_map which is defined in the super class. Also, it _storage_map is out of sync, then findOne will bring it back to sync (and take longer).

Parameters:
Name Type Description
whokey string
Source:
Returns:
  • the value stored
Type
object

has(whokey) → {string|boolean}

Parameters:
Name Type Description
whokey string
Source:
Returns:
  • returns fals if the elementis not in the _whokey_to_ids map. Otherwise, the id.
Type
string | boolean

hash(data) → {string}

Parameters:
Name Type Description
data string
Source:
Returns:

the hash of the data

Type
string

hash_from_persitence(obj) → {string}

Returns the intrinsic hash key

Parameters:
Name Type Description
obj object
Source:
Returns:
  • object hash
Type
string

initialize(conf)

Calls the initializer for FilesAndRelays and the immediate LocalStorageSerialization

Parameters:
Name Type Description
conf object
Source:

newer(remote_obj, up_obj) → {boolean}

Parameters:
Name Type Description
remote_obj object
up_obj object
Source:
Returns:
Type
boolean

setPersistence(presistence_db)

quite possibly another DB made fore keeping objects around for a long time will be used

Parameters:
Name Type Description
presistence_db *
Source:

(async) set_key_value(whokey, data) → {boolean}

Searches for the id of the data object by using a local identity, where the id mapped by the whokey refers to a universal wide area identity of the data.

If it finds a local copy of the object, it will check to see if the local persistence storage keeps a copy. Given there is a local copy, this method calls get_key_value primarily for loadging instances of PageableMemStoreElement as it is already established the object exists.

If it does not find a local copy of the object, it will check to see if the larger world knows about it. Without a local copy, the object _id cannot be known, so it searches for the object using the whokey using the field _whokey_field, which is hopefully known universally. (It is expected the application has standardized some field and way of obtaining a universal id for the objects stored here.) The search performed is the same as in get_key_value, however this method attempts to update the object data. It calls load_missing_or_update to perform this operation.

Once the knowledge of the object is established, it will make sure the data is updated and synced with the local disk.

If the object has not been seen anywhere, this method will store it as a the definitive entry and send out to the wider area.

Parameters:
Name Type Description
whokey string
data object
Source:
Returns:
Type
boolean