Hi Garry,
Sorry for delayed reply - just came back from a week-long trip.
> a) In the modeler, on the DataMap Screen I would add two new
> tabs for DbAttributePrototypes (DAP) and ObjAttributePrototypes (OAP).
> b) These would look essentially the same as their counterparts
> on the DbEntity and ObjEntity attribute tabs.
>
> c) The existing attribute tabs would have a column for a
> prototype combo box that would list the appropriate prototypes from
> the DataMap tabs.
>
> d) If a prototype is selected it would override all of the
> attributes except for PK (on DbAttributes)
Here is the issue for prototypes feature tracking -
http://objectstyle.org/jira/secure/ViewIssue.jspa?key=CAY-225.
The design is still a bit vague in my head, but I was thinking that
prototypes should be easy to share among multiple DataMaps or projects.
So I thought we should put DAP and OAP definitions in a separate
"prototype" DataMap.
Another issue is where we store OAP and DAP. I think we can avoid
changing current DataMap structure (i.e. avoid storing prototype
definitions at the DataMap level). A "prototype" DataMap can have a
pair of normal OE and DE. We can use a naming convention like EOF does
internally (e.g. call those entities "OEPrototype" and "DEPrototype"),
but present a simpler Modeler interface to the user hiding these
details.
Other than that (a) - (d) look reasonable to me.
> e) Additionally I would like to add additional capability to the
> DbAttribute that would allow a custom java objects be created instead
> of the standard jdbc mapping from the table.
Take a look at the existing ExtendedType feature in Cayenne -
http://objectstyle.org/cayenne/userguide/access-stack/extended-
types.html. With ExtendedTypes you can use arbitrary Java classes for
attributes. There are a few limitations though that we need to address:
* ExtendedTypes currently have to be defined manually in the code. We
need to allow their definition in the Modeler (per DataMap? in
prototypes DataMap?). Also note that DbAdapters often load their own
ExtendedTypes to do DB-specific tricks. So whatever design we come up
with should keep this in mind.
* It doesn't work at DbAttribute level, only at ObjAttribute, and thus
doesn't work well with pure data rows. So I was thinking about defining
new "javaType" property for DbAttribute, and making "type" property
optional for ObjAttribute (so that it can use underlying DbAttribute
type definition).
> g) While I am in there I would like to be able to add a read
> only flag on both dbAttributes and objAttributes. If the linked
> dbAttribute is read only then the objAttribute is read only also.
My +1 for the general idea - other people requested that in the past.
However I think we should follow current pattern of defining
"read-only" flag at the object level. Currently ObjEntity has it, but
DbEntity does not. So defining it per ObjAttribute (and maybe also
ObjRelationship) should be enough. Any reason why this is not
sufficient?
Andrus
This archive was generated by hypermail 2.0.0 : Sun Apr 24 2005 - 20:39:24 EDT