If anytime during a transaction an error occurs, the database will be rolled back to the last commit. The length of a database transaction can be controlled by the programmer using the #beginTransaction,#commitTransaction, and #rollbackTransaction messages. If a transaction is not manually begun before storing an object, MinneStore will automatically begin and commit(or rollback) the transaction.
Complex objects can be stored separately or together
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.
Efficient object indexing
Object sets can be indexed in as many ways as you like. Usually indexes are on "primitive" objects like strings and integers which can be easily used in queries. Indexes are stored in multiple files. This makes for less memory usage and allows different users to update the index at the same time (as long as they aren't updating the same part of the index).
Optimistic object locking for multi-user access
Each time an object is stored, its version number is updated. An exception will be signaled during storing if an object has been changed by another user since it was read.
Object identity
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. In the future I may supply a way to clear the instance cache and force a new database read.
Aspects are instantiated as needed
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 large complex objects.
An English-like query language
The syntax for querying is very english-like and easy to use.