Carbonado TODO

== Bugs ==

* Support LOBs in replicated repository.
* Merge sort crashes if it needs to write Storables which contain
  LOBs. Solution is to support serialization by the Storable itself
  somehow. This is also required for the RemoteRepository.


== Query Enhancements ==

* Support 'like' operator. For example: "name like ?%". Also define "!like" operator.
* Define basic aggregation functions, Query.min, Query.max, and
  Query.distinct (returns a Cursor<Object>). Optimizations exist at the index layer.
* Define Query.fetch(int skip, int limit), fetch(int, int, int prefetch)
  methods. Should these be separate methods, to better support query
  optimization? Query.skip(500).limit(100).prefetch(50).fetch(); prefetch?
  buffer? chunk? accumulate? collect? cache? Should this be a parameter to
  fetch, or does it look like a limit?
* Support outer join in query filter, perhaps using (.) instead of regular dot.
  Might be confusing: "address(.)city = ?". This might make more sense:
  "(address).city = ?". It says "address" is optional. Join property must be
  defined as Nullable to support outer join query.
* Support query by example: Query<S> Storable.query()
* Support basic sub-queries:
    Query<Foo> fooQuery = fooStorage.query("name in ?.name").with(barStorage.query(...));
    Can also use "!in" operator. When placeholder is of the form "?.<name>",
    parameter may be a Query, Cursor, Iterator, Collection or array. When just
    "?", parameter cannot be a Query. Correlated sub-queries cannot be supported
    with this syntax, but then correlated sub-queries generally perform poorly.
* Support simple views. The Query object has a "view" method, which returns
  another Query. The implementation effectively locks down the Filter such that
  it is always "and"ed with the Filter from the source Query. The view method
  throws an IllegalStateException if any blank parameters.


== Performance ==

* Join optimization
* Support partial lookup:
      // For partial lookup, identify which properties you want.
      // Selections are overridden when calling reject.
      Query<S> select(String...);

      // For partial lookup, identify which properties you don't want.
      // Rejections are overridden when calling select.
      Query<S> reject(String...);

* With support for partial lookup, optimize query by index. If index contains
  all desired master properties, then don't load master.
* For JDBC repo, perform eager load of joined properties which participate in
  the query filter. Don't do this if properties rejected.
* JDBC repository should have a mechanism to determine (with some reasonable
  reliability) if a trigger exists in the database which will perform the
  action that the carbonado trigger will, and disable the carbonado trigger if
  so, and (the payoff) allow bulk operations to function in bulk mode rather
  than one-by-one (specifically, deletes).


== Utilities ==

* Unclosed resource detection and warning mechanisms
* Enhanced logging for Replicated and Writethrough repositories.
* Repository importer/exporter


== Misc Features ==

* Allow property annotation to be specified on either accessor or
  mutator. Still only one type allowed, however.
* Support sysdate() by adding method on Repository.
* Add @Auto annotation. Property not needed for insert, and if on primary key,
  assumes it is an identity property. @Auto is only for repositories that have
  hidden triggers and identity columns. Its pretty much a JDBC-only
  feature. Sadly, there's no real way to verify if an @Auto property was
  actually set to a value or not. BDB repository can support @Auto for primary
  key by mapping to sequence whose name is the Storable class name.
* Add @Default annotation.
* Support non-transactional truncate operation, on the Storage object. If in a txn,
  throw IllegalStateException. If any Lobs, call normal deleteAll instead to ensure
  referenced Lobs get deleted.
* Support foreign key definition on @Join, which automatically installs check
  triggers. Also support cascade delete option.


== Long Term Ideas ==

* RemoteRepository
* PartitionedRepository
* In-memory repository, which will likely use ConcurrentSkipListMap from jdk1.6.
* More work in replicated repository to decide if throwing repair exception is justified.
* Data model versioning (when do we remove indexes?)