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.
- Distributed, scalable operation.
- Dynamic object (classes and attributes)

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

- Support for all primitive array types
- Support for primitive values inside lists
- Transaction and connection leak detection
- Strict finder, meaning no subclasses returned, only the exact class
- Make history retention configurable! (up to seconds)
- Performance/monitoring with a separate client (pretty graphs and such)
- Performance enhancements:
  - Containers should save which types were saved in them, so they
    can be read without pre-selecting possible classes.
  - 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.
- If environment is java 5, lists and maps can use the meta-information
  to select.
- Make new TX_EMBEDDED transaction which sees the parents modifictations
  just commits separately
- Max and min memory of cache configurable
- Scripts: data snapshot
- Aggregate functions (sum, count, etc.)
- Subselects
- CrystalReport / OpenReport integration
- Allow for similar attributes in classes, and select those separately,
  or name those attribute while selecting!

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.