[Checkins] SVN: z3c.dobbin/trunk/ Updated documentation.
Malthe Borch
mborch at gmail.com
Wed Jul 2 17:57:44 EDT 2008
Log message for revision 87940:
Updated documentation.
Changed:
U z3c.dobbin/trunk/CHANGES.txt
U z3c.dobbin/trunk/README.txt
U z3c.dobbin/trunk/docs/DEVELOPER.txt
-=-
Modified: z3c.dobbin/trunk/CHANGES.txt
===================================================================
--- z3c.dobbin/trunk/CHANGES.txt 2008-07-02 21:56:01 UTC (rev 87939)
+++ z3c.dobbin/trunk/CHANGES.txt 2008-07-02 21:57:42 UTC (rev 87940)
@@ -1,9 +1,13 @@
Change log
==========
-0.3.1 dev
----------
+0.3.1
+-----
+- Use native UUID column type (available on PostgreSQL); compatibility
+ with SQLite is preserved due to its weak typing.
+ [malthe]
+
- Basic type factories are now registered as components.
[malthe]
Modified: z3c.dobbin/trunk/README.txt
===================================================================
--- z3c.dobbin/trunk/README.txt 2008-07-02 21:56:01 UTC (rev 87939)
+++ z3c.dobbin/trunk/README.txt 2008-07-02 21:57:42 UTC (rev 87940)
@@ -5,11 +5,12 @@
semi-transparent object persistance model.
It relies on descriptive attribute and field declarations based on
-zope.interface and zope.schema.
+zope.interface and zope.schema. Strong typing is supported (and
+encouraged when possible), but not required.
-Tables are created automatically with a 1:1 correspondence to an
-interface with no inheritance (minimal interface). As such, objects
-are modelled as a join between the interfaces it implements.
+Tables are created on-the-fly with 1:1 correspondence to interfaces
+with no inheritance (base interface). As such, objects are modelled as
+a join between the interfaces they implement.
Authors
-------
Modified: z3c.dobbin/trunk/docs/DEVELOPER.txt
===================================================================
--- z3c.dobbin/trunk/docs/DEVELOPER.txt 2008-07-02 21:56:01 UTC (rev 87939)
+++ z3c.dobbin/trunk/docs/DEVELOPER.txt 2008-07-02 21:57:42 UTC (rev 87940)
@@ -1,50 +1,41 @@
Developer documentation
=======================
-This section details the object persistence model and the relations
-machinery.
+Objects are mapped by their specification. Polymorphic attributes are
+declared as interface attributes; strong typing may be declared using
+schema fields; Attributes that are not declared in a schema or
+interface are considered volatile.
-Introduction
-------------
+Unique identifiers (UUID)
+-------------------------
-Objects that need persisting are required to declare their attributes
-in an interface. Attributes that are not declared are considered
-volatile.
+A 16-byte unique identification number is used.
-Concrete attributes may be strongly typed using the schema fields that
-correspond to their type; polymorphic attributes are available using
-relational properties.
-
Relations
---------
-There are two kinds of objects that can be related: instances and
-rocks. Relations are polymorphic such that they support both kinds.
+Polymorphic attributes are always stored using foreign key
+relations. This is handled transparently by the framework.
-An attribute can hold a single relation or many, using one of the
-built-in sequence types: list, tuple, set, dict.
+The target of a relation may be a basic type such as a string,
+integer, tuple or list, or it may be a mapped object.
-The following fields allow polymorphic relations of any kind:
+The following fields allow polymorphic relations of any kind with the
+type declared on assignment.
* zope.schema.Object
* zope.interface.Attribute
-Additional structure can be declared using the sequence fields:
+Collections are instrumented objects and may be declared using the
+sequence fields:
* zope.schema.List
* zope.schema.Dict
* zope.schema.Set
-When translated to column in a table, all relations are soup object
-references; the soup specification will reflect the type.
+A note on dictionaries: Dictionaries are keyed by (unicode)
+string. Mapped instances may be used as keys in which case a string
+representation of the unique instance identifier is used. Dictionaries
+support polymorphic values with type set on assignment.
-Essentially, all polymorphic relations are many-to-many from a
-database perspective.
-Collections
------------
-
-Dictionaries are keyed by (unicode) string. Soup objects may be used
-as keys in which case a string representation of the UUID is
-used. Dictionaries are polymorphic such that any kind of value may be
-assigned for an entry.
More information about the Checkins
mailing list