Author: ianb
Date: 2004-08-25 09:38:57 -0400 (Wed, 25 Aug 2004)
New Revision: 202
Modified:
trunk/SQLObject/docs/FAQ.txt
Log:
New FAQ about reloading modules
Modified: trunk/SQLObject/docs/FAQ.txt
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/SQLObject/docs/FAQ.txt 2004-08-25 02:06:07 UTC (rev 201)
+++ trunk/SQLObject/docs/FAQ.txt 2004-08-25 13:38:57 UTC (rev 202)
@@ -197,3 +197,32 @@
.. raw:: html
:file: ../examples/snippets/image-binary-sqlite.html
=20
+
+Reloading Modules
+-----------------
+
+If you've tried to reload a module that defines SQLObject subclasses,
+you've probably encountered various odd errors. The short answer: you
+can't reload these modules.
+
+The long answer: reloading modules in Python doesn't work very well.
+Reloading actually means *re-running* the module. Every ``class``
+statement creates a class -- but your old classes don't disappear.
+When you reload a module, new classes are created, and they take over
+the names in the module.
+
+SQLObject, however, doesn't search the names in a module to find a
+class. When you say ``ForeignKey('SomeClass')``, SQLObject looks for
+any SQLObject subclass anywhere with the name ``SomeClass``. This is
+to avoid problems with circular imports and circular dependencies, as
+tables have forward- and back-references, and other circular
+dependencies. SQLObject resolves these dependencies lazily.
+
+But when you reload a module, suddenly there will be two SQLObject
+classes in the process with the same name. SQLObject doesn't know
+that one of them is obsolete. And even if it did, it doesn't know
+every other place in the system that has a reference to that obsolete
+class.
+
+For this reason and several others, reloading modules is highly
+error-prone and difficult to support.
|
