MinneStore^TM Features

MinneStore can store a network of inter-related objects and maintain their relationships. For example, a geneological database where each person object is either directly or indirectly related to many other person objects. Related objects are automatically instantiated from the database as needed instead of being read in all at once.

Any unhandled error (e.g. optimistic locking signals an invalid version error) that occurs inside a transaction block will cause a rollback. If an object storage command (db store: anObject) is not already inside an explicit transaction then MinneStore will implicitly begin and commit(or rollback) the transaction for you.

A complex object can be stored in multiple "object sets" or all together in one. When an object is stored, all its "aspects" are stored as well. These aspects can be indexed just like any other object. Storing of recursive complex objects (two objects pointing to each other) is supported as well. When a complex object is retrieved from disk its related objects (aspects) are transparently retrieved when needed.

Object sets can have any number of indexes. Usually indexes are on "primitive" objects like strings and integers which can be easily used in queries.

This feature will not be available until version 2.1.
Each time an object is stored, its version number is updated. If an object is updated on disk by someone else between the time you read and store the same object yourself, then an MSInvalidVersionError will be signaled.

If an object is read more than once, the subsequent reads will return the exact same object as the first read. This is to protect object identity. It is possible to remove an object from the cache so a new instance will be read from the database.

When a complex object is read, its aspects are not read until a message is sent to them. This means that memory can be more efficiently managed for when an object has many, far-reaching relationships.

An English-like query language