This is the manual for older MicroStream versions (Version < 5.0).
The new documentation (Version >= 5.0) is located at:
The default MicroStream implementation fully supports the Java transient field modifier. Class members marked transient will not be persisted.
It is possible to override the default behavior by implementing a custom PersistenceFieldEvaluator
.
This is the manual for older MicroStream versions (Version < 5.0).
The new documentation (Version >= 5.0) is located at:
Beside long store(Object instance)
MicroStream provides some convenience methods to store several objects at once:
void storeAll(Iterable<?> instances)
Stores the passed instance in any case and all referenced instances of persistable references recursively, but stores referenced instances only if they are newly encountered (e.g. don't have an id associated with them in the object registry, yet and are therefore required to be handled). This is useful for the common case of just storing an updated instance and potentially newly created instances along with it while skipping all existing (and normally unchanged) referenced instances.
long[] storeAll(Object... instances)
Convenience method to store multiple instances. The passed array (maybe implicitly created by the compiler) itself is NOT stored.
MicroStream does not provide explicit transactions, every call to a store method is automatically a transaction. A store operation is an atomic all or nothing operation. if the store call is successful all data is written to the storage. Otherwise no data is persisted. Partially persisted data will be reverted.
This is the manual for older MicroStream versions (Version < 5.0).
The new documentation (Version >= 5.0) is located at:
MicroStream is designed to work with object graphs. Thus, storing data means to store an object graph. This includes the object's value fields and references to other objects. Storing an object will also store all instances referenced by this objects that have not been stored before. While storing your data most of the work MicroStream performs for you. You only need to call the store method on the correct object. The rule is: "The Object that has been modified has to be stored!".
Storing objects that are not part of an object graph is most likely pointless.
See Getting Started how to create a database with a root instance.
To store the registered root instance just call the storeRoot()
method of a EmbeddedStorageManager
instance.
To store a newly created object, store the "owner" of the object. In the example below a new object is created and added to the myObjects
list of the root object. Then the modified list gets stored. This will also store the new object.
Before storing a modified object keep in your mind that the modified object needs to be stored.
In case of a value types, like int
, it is the object that has the int field as a member:
Don't forget immutable objects
Immutable objects like String
cannot be modified.
Assigning a new value to a String does not modify the String object. Instead a new String instance is created and the reference is changed!
The full code for the example is on GitHub.
This is the manual for older MicroStream versions (Version < 5.0).
The new documentation (Version >= 5.0) is located at:
In some cases, it can be necessary to store modified encapsulated objects that cannot be a accessed from your code.
In the upper code snippet the "hidden" object cannot be accessed by store(myForeignObject.hidden)
if no getter is available. To allow such hidden objects to be stored after they have been modified you have to options:
Set the global storing strategy of the MicroStream instance to eager storing or
Implement and set a custom PersistenceEagerStoringFieldEvaluator
for this field.
To increase performance use immutable sub-graphs as often as possible. Storing those with the provided convenience storing methods or using a thread local storer to insert those sub-graphs concurrently can give a great performance boost.
This is the manual for older MicroStream versions (Version < 5.0).
The new documentation (Version >= 5.0) is located at:
The MicroStream engine supports two general storing strategies: Lazy and eager storing. By default, MicroStream uses the lazy storing strategy.
These storing strategies differ in the way how objects, referenced by the object to be stored are handled if those referenced objects had already been stored.
Lazy storing is the default storing mode of the MicroStream engine.
Referenced instances are stored only if they have not been stored yet. If a referenced instance has been stored previously it is not stored again even if it has been modified.
That's why modified objects must be stored explicitly
In eager storing mode referenced instances are stored even if they had been stored before. Contrary to Lazy storing this will also store modified child objects at the cost of performance.
To use lazy or eager storing explicitly, get an instance of the required Storer
and use it's store methods:
Available Storer
s are:
storage.createLazyStorer()
storage.createEagerStorer()
Standard storing:
storage.createStorer()
will provide corresponding Store
r instances.
Beside the 'global' lazy or eager storing strategies MicroStream allows to implement an individual handling for the storing behavior. See PersistenceEagerStoringFieldEvaluator for details.