Per our phone conversation with Misha, here is a description of the design
changes I am about to make:
Current relationship of ObjAttribute -> DbAttribute is a "to-one" approach.
It means that ObjAttribute will *always* map to a single table column. I
want to change that.
Instead, internally, each ObjAttribute would map to a
org.objectstyle.cayenne.exp.Expression. In a simple case (table column),
expression type would be DB_NAME (does not exist yet, see DB_PATH). But it
can also be expression of type COUNT, AVG, MAX (aggregates are not defined
yet, I will add them soon), ADD, SUBTRACT and many more. This means that we
can represent almost any real life mapping scenario without SQL hardcoding.
So, API for ObjAttribute will change like that:
1. "DbAttribute getDbAttribute()" and "setDbAttribute(DbAttribute)" will be
removed.
2. "Expression getMappingExp()" and "void setMappingExp(Expression)" will
be added.
Having said that, I suggest that for the initial release we DO NOT
implement any visible "weird" mapping support in the tools (but still
having options to do it via API). Instead this will be used from query
package. SelectQuery should allow to define any kind of result attributes
based on root entity, even things that are not defined in the root
ObjEntity. Of course in such cases mapping will not be done to a predefined
DataObject subclass. Rather to a list of some sort of generic objects or
something like HashMaps will be returned on select.
This morning on the plane I developed this approach on paper and played
with different scenarios/implications. It turns out to be very flexible and
allows OO-style for SELECT queries of almost any type - with GROUP
BY/HAVING, UNIONS, etc. I will be working on the new API this week. I have
a design in place, so it should be pretty straightforward to implement.
Sorry for the long message.
Andrei
This archive was generated by hypermail 2.0.0 : Mon Jan 21 2002 - 19:36:53 EST