[SQL-CVS] r892 - trunk/SQLObject/docs

[<sub...@co...>]

Author: test
Date: 2005-08-05 20:23:19 +0000 (Fri, 05 Aug 2005)
New Revision: 892

Modified:
   trunk/SQLObject/docs/SQLObject.txt
   trunk/SQLObject/docs/TODO.txt
Log:
Moved some stuff around, trimmed a little excess

Modified: trunk/SQLObject/docs/SQLObject.txt
===================================================================
--- trunk/SQLObject/docs/SQLObject.txt	2005-08-05 04:04:47 UTC (rev 891)
+++ trunk/SQLObject/docs/SQLObject.txt	2005-08-05 20:23:19 UTC (rev 892)
@@ -7,8 +7,8 @@
 Author, Site, and License
 =========================
 
-SQLObject is by Ian Bicking (ia...@co...).  The website is
-sqlobject.org__.
+SQLObject is by Ian Bicking (ia...@co...) and `Contributors
+<Authors.html>`_.  The website is sqlobject.org__.
 
 __ http://sqlobject.org
 
@@ -108,29 +108,6 @@
 does not have to be designed with SQLObject in mind, and the resulting
 classes do not have to inherit the database's naming schemes.
 
-Future
-======
-
-Here are some things I plan:
-
-* More databases supported.  There has been interest and some work in
-  the progress for Oracle, Sybase, and MS-SQL support.
-* Better transaction support -- right now you can use transactions
-  for the database, but the object isn't transaction-aware, so
-  non-database persistence won't be able to be rolled back.  
-* Optimistic locking and other techniques to handle concurrency.
-* Profile of SQLObject performance, so that I can identify bottlenecks.
-* Increase hooks with FormEncode (unreleased) validation and form
-  generation package, so SQLObject classes (read: schemas) can be
-  published for editing more directly and easily.
-* Automatic joins in select queries.
-* More kinds of joins, and more powerful join results (closer to how
-  `select` works).
-
-See also the `Plan for 0.6`__.
-
-.. __: Plan06.html
-
 Using SQLObject: An Introduction
 ================================
 
@@ -220,18 +197,6 @@
 (``middleInitial`` has a default, so it will be set to ``NULL``, the
 SQL equivalent of ``None``).
 
-.. note::
-
-   In SQLObject NULL/None does *not* mean default.  NULL is a funny
-   thing; it mean very different things in different contexts and to
-   different people.  Sometimes it means "default", sometimes "not
-   applicable", sometimes "unknown".  If you want a default, NULL or
-   otherwise, you always have to be explicit in your class
-   definition.
-
-   Also note that the SQLObject default isn't the same as the
-   database's default (SQLObject never uses the database's default).
-
 You can use the class method `.get()` to fetch instances that
 already exist::
 
@@ -259,6 +224,18 @@
     >>> p is p2
     True
 
+.. note::
+
+   In SQLObject NULL/None does *not* mean default.  NULL is a funny
+   thing; it mean very different things in different contexts and to
+   different people.  Sometimes it means "default", sometimes "not
+   applicable", sometimes "unknown".  If you want a default, NULL or
+   otherwise, you always have to be explicit in your class
+   definition.
+
+   Also note that the SQLObject default isn't the same as the
+   database's default (SQLObject never uses the database's default).
+
 Columns are accessed like attributes.  (This uses the ``property``
 feature of Python 2.2, so that retrieving and setting these attributes
 executes code).  Also note that objects are unique -- there is

Modified: trunk/SQLObject/docs/TODO.txt
===================================================================
--- trunk/SQLObject/docs/TODO.txt	2005-08-05 04:04:47 UTC (rev 891)
+++ trunk/SQLObject/docs/TODO.txt	2005-08-05 20:23:19 UTC (rev 892)
@@ -1,10 +1,19 @@
 TODO
 ----
 
-See also some `long-term ideas`__.
-
-.. __: Plan06.html
-
 * ``_fromDatabase`` currently doesn't support IDs that don't fit into
   the normal naming scheme.  It should do so.  You can still use
   ``_idName`` with ``_fromDatabase``.
+* More databases supported.  There has been interest and some work in
+  the progress for Oracle, Sybase, and MS-SQL support.
+* Better transaction support -- right now you can use transactions
+  for the database, but the object isn't transaction-aware, so
+  non-database persistence won't be able to be rolled back.  
+* Optimistic locking and other techniques to handle concurrency.
+* Profile of SQLObject performance, so that I can identify bottlenecks.
+* Increase hooks with FormEncode (unreleased) validation and form
+  generation package, so SQLObject classes (read: schemas) can be
+  published for editing more directly and easily.
+* Automatic joins in select queries.
+* More kinds of joins, and more powerful join results (closer to how
+  `select` works).