[Chandler-dev] Type Definitions for sharing format API

[Phillip J. Eby]

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.