At 01:52 PM 9/22/2006 -0400, Phillip J. Eby wrote:
Open Issues
-----------
* The record type I've been using as an example above should probably
actually define the "lastModifiedBy" field's type as being a reference to
the "itsUUID" field: a self-referential dependency. I don't currently
have a way to express this.
...
* There's still no way to express what field(s) represent a record's
primary key. In the examples we've played with so far, this tends to be
either a UUID or the entire record is its primary key, but I'm not sure
that other combinations can't arise. (Primary key definition is needed in
order to implement a "diff" or "delta" mechanism for transmitting
incremental updates.)
After pondering these issues for a bit, I think that the easiest way to
solve them is to change the proposed API for record type declaration to
look like this instead (using the tagging example from the original proposal):
class itemrecord(sharing.Record):
itsUUID = sharing.field(schema.UUID)
title = sharing.field(256)
body = sharing.field(sharing.LobType)
createdOn = sharing.field(sharing.DateType)
description = sharing.field(1024)
lastModifiedBy = sharing.field(itsUUID)
sharing.typeinfo(uri="URI for 'itemrecord'", key=itsUUID)
class tag(sharing.Record):
itsUUID = sharing.field(itemrecord.itsUUID)
tagName = sharing.field(32)
sharing.typeinfo(uri="URI for 'tag'", key=itsUUID)
class tagging(sharing.Record):
item = sharing.field(itemrecord.itsUUID)
tag = sharing.field(tag.itsUUID)
sharing.typeinfo("URI for 'tagging'", key=(item,tag))
The idea here is that passing in a number instead of a type to
``sharing.field`` would produce a text field of that length. Passing in a
field results in a linkage between fields/record types, for inter-record
dependency handling. Keys are specified as a field, or as a tuple of
fields. Having the key makes it possible to create single-record deltas by
"subtracting" one record from another. For example, if I create these records:
t1 = tag(uuid1, "dummy name")
t2 = tag(uuid1, "other name")
Then ``t1-t2`` would equal ``t1``, and ``t1-t1`` would equal
``sharing.NoChange``. More precisely, subtracting one record from another
would produce a record with ``sharing.NoChange`` in every unchanged field
*except* for key fields. If all non-key fields are unchanged, the result
of the subtraction would be ``sharing.NoChange``.
(Notice, by the way, that this implies an object's primary key can never
change, or it will no longer be updateable. Is this going to be a problem?)
* A new potential issue is that of type representation changes. If you
change the definition of a type or its representation between schema
versions, you could alter the schema in an incompatible way. I'm not sure
that this is really a *new* issue, just that the type aliasing machinery
might make it easier to make this mistake. I need to give this some more
thought; suggestions are welcome.
In general, actually, any feedback or thoughts on the open issues (or the
current state of the API proposal in general) would be useful. Thanks.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
