summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorBrian S. O'Neill <bronee@gmail.com>2006-08-31 05:30:25 +0000
committerBrian S. O'Neill <bronee@gmail.com>2006-08-31 05:30:25 +0000
commite2d8487a685160f3506cc3b095e71b36e109a984 (patch)
treeb94ab5d6f2331ddc6f49dd3982bdebeca8980764
parent9f7215e4399bb4058cdfa62bf4d2fd5ec1dca05c (diff)
Add TODO
-rw-r--r--TODO.txt95
1 files changed, 95 insertions, 0 deletions
diff --git a/TODO.txt b/TODO.txt
new file mode 100644
index 0000000..1fe3c2a
--- /dev/null
+++ b/TODO.txt
@@ -0,0 +1,95 @@
+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?)
+
+