[z3-checkins] r24076 - z3/sqlos/trunk/src/sqlos

[jinty at codespeak.net]

Author: jinty
Date: Tue Mar  7 17:02:43 2006
New Revision: 24076

Modified:
   z3/sqlos/trunk/src/sqlos/README.txt
Log:
Remove documentation that was obviously out of date and, in my opinion, inappropriate for a top level README.

Modified: z3/sqlos/trunk/src/sqlos/README.txt
==============================================================================
--- z3/sqlos/trunk/src/sqlos/README.txt	(original)
+++ z3/sqlos/trunk/src/sqlos/README.txt	Tue Mar  7 17:02:43 2006
@@ -342,79 +342,3 @@
           />
 
 .. _DublinCore: http://dublincore.org
-
-
-SQLObjectAuthSource
--------------------
-
-XXX Write about SQLObjectAuthSource.
-
-
-Notes about transaction interoperability
-----------------------------------------
-
-SQLObject, starting on version 0.6, has a new feature called ``lazy
-updates``. This feature allows for batching changes in a controlled
-way so that only one ``UPDATE`` statement is run for a set of
-changes. This is particularly useful for our Zope integration, because
-when you edit an object, all of it's attributes are passive of being
-changed. This can potentially cause a big set of ``UPDATE`` queries to
-be fired. The triggering of the ``UPDATE`` query is done manually, by
-calling either ``sync()`` or ``syncUpdate()`` on the SQLObject-based
-object (``sync()`` refetches the the data from the database, which
-``syncUpdate()`` does not).
-
-Of course, for a more transparent integration, it shouldn't be
-required for the user to do that, but instead, when Zope (ZODB) does a
-transaction commit (usually on request boundaries, but can happen at
-any given time), it ``sync()`` should be called for any objects marked
-as ``dirty``, so that their ``UPDATE`` queries are run. Also, the
-order that the queries are to be issued should follow the order which
-objects get dirty, so that any constraints/triggers can do their job
-accordingly.
-
-Given the current state of ZODB's transaction machinery, there is a
-relatively non-intrusive change that can be done to ``sqlos`` to
-achieve this goal. Here we will explain the implementation.
-
-In Zope, each request is served by a ZServer thread. For each request,
-a transaction (bound to a thread id) is created. When the request
-ends, the transaction gets commited.
-
-ZODB 4 (currently postponed for lack of time) introduced the concept
-of ``joining`` a transaction. For objects to join a transaction, they
-must either implement ``IDataManager``, or have a ``_p_jar`` attribute
-which implements IDataManager. When the ``main`` (or, original)
-transaction is about to commit, it's ``prepare()`` method is called
-first, then ``commit()`` is called. When the transaction gets aborted,
-it's ``abort()`` method is called. The main transaction makes sure
-that for every ``IDataManager`` that joined the transaction, it's
-``prepare()``, ``commit()`` and ``abort()`` method are called. The
-order of the registered objects is given by calling the ``sortKey``
-method on the IDataManager if available, or by
-``id(<IDataManager>)``.
-
-Our solution consists of:
-
-- Create a SQLObjectTransactionManager that implements
-  IDataManager. This object will keep track of the dirty objects for a
-  transaction.
-
-- Anytime a SQLObject-based object gets its ``dirty`` bit set, the
-  object is registered with the current SQLObjectTransactionManager.
-
-- If an object gets it's dirty bit set to ``False``, it may mean that
-  this object's ``sync()`` method has been called. We *could* call
-  ``sync()`` on all the dirty objects registered before, but this
-  would increase complexity a lot. For now, we just recommend *not*
-  calling ``sync()`` or ``syncUpdate()`` manually inside transactions.
-
-- SQLObjectTransactionManager needs to have a ``sortKey()`` that
-  returns a value smaller than ZopeDBTransactionManager's (which
-  currently doesn't implement this method, so
-  ``id(<ZopeDBTransactionManager>)`` is used). This is so that the
-  ``UPDATE`` queries get sent before the RDB cursor's ``commit()`` is
-  called.
-
-- Create a SQLOS class that subclasses SQLObject to override ``dirty``
-  and enable lazy updates by default.