1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
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?)
|
