Features
~~~~~~~~

- Easy to use
- No configuration necessary.
- Small library size.
- Supports PostgreSQL, MySQL, Oracle, HSQLDB
- Own straight-forward, simple query language
- Supports transactions
- Supports polymorphism (selecting for superclass will return all subclasses too)
- Can save any bean (does not use Serializable/Externalizable stuff)
- Transparent handling of references to other beans
- Can handle circular-, or self-references
- Can save Lists and Maps
- View selects
- All queries are now transactions safe, no matter what you do,
  result lists stay the same.

Wishlist/TODO
~~~~~~~~~~~~~

- Enable distributed working (multiple Stores to a single database)
  - Priority locks: enabled batch jobs to always complete
- Transaction and connection leak detection
- Make history retention configurable! (up to seconds)
- Performance/monitoring with a separate client (pretty graphs and such)
- Performance enhancements:
  - Do not save/delete objects but until they are referred to in the
    same transaction. If not, then they should be written simply on the
    end of the transaction.
  - Inside a transaction updates should be batched together, and executed
    on commit only, or earlier if there was a query for given modifications
    which forces the updates to execute.
  - Remove persistence_ids table, and make the classname part of the key,
    this way, persistence_ids will not have to be joined to each query,
    and each table can have it's own ids.
  - OnDemand stuff should keep track of changes, so it does not have
    to be compared item-for-item with itself to extract changes.
- On-demand lists and maps should rely on standard query measures
- On-demand lists and maps should work as lazy-lists, with the
  capability of handling virtually unlimited resultsets!
- On-demand lists should not be distinct (it should allow multiple
  entries of same object)
- On-demand lists should keep ordering
- Set support
- Locking: Maybe the library should support locking, serizalizable and
  read-only, etc. object locking.
- Internal: Export type handling (maps and lists) to specific type
  handlers. These will also handle query language constructs, and
  marshalling/unmarshalling.
  This will make type handling extensible.
- Make new TX_EMBEDDED transaction which sees the parents modifictations
  just commits separately
- Max and min memory of cache configurable
- Scripts: data snapshot

Design considerations (note to self)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

- No configuration XMLs. If it is really-really needed, and
  no way around it, with no defaults to use... Think harder, and find a way!
- Full abstraction from database layer
- Simple beans will be used, no interfaces or methods necessary,
  similar to in-memory-management
- Query language will be based on objects, for example
  object.name = 'ni', or object['ni']=foobar (last indicating hashmap
  handling)
- Non-transient accessible properties will all be saved,
  maps as well as lists, and custom beans.