|
From: Luke O. <lu...@me...> - 2003-04-22 16:05:44
|
> Pass a string with foreignKey, not the actual class. This
> avoids
> circular dependencies.
>
> Really, it would be great to have the actual class instead of a
> string
> here. That way, it would be trivial to find out the table name...
> What exactly are the problems of circular dependencies? In the
> person, phonenumber example, I see that phonenumber would reference
> person, but I don't see any reference back from person to
> phonenumber.
Circular dependencies are a very real issue, I mentioned in an email a
while back that classRegistry and needSet don't completely solve this
issue either, but...
Circular dependency happens when you have a foreignKey in one class,
and in the linked class a MultipleJoin back to the first class. If
you specify by class instead of name, that means you need to import
the other class in each:
Class A: import Class B (for foreignKey)
leads to
Class B: import Class A (for join)
and Python blows up ("unable to import Class A") because it's already
in the midst of importing class A.
Specifying by string solves half this problem, but still leads to the
issue where a third module (SQLObject-derived or not) imports Class
A, then accesses the foreignKey, and SO.classRegistry has not heard
of Class B yet. So this third module (which should not really have to
know about class B's specific location at all) has to import class B.
I haven't found a good solution to this problem. Here's one
possibility however:
Since the circular dependency problem is with imports that happen at
*module import* time, it would be conceivable to add a delayed import
feature, so that when an SQLObject is *instantiated* any remaining
classes are imported, and therefore put into needSet. Perhaps
something like:
class B(SQLObject):
_imports = ['Objects.A','OtherObjects.C']
This would have the requirement that no SQLObject-derived class
*explicitly* import any other SQLObjects, only through this
mechanism. It's not pretty, but I'm really cringing at our current
situation where a class that only directly deals with one or two
SQLObject classes is needing to import everything those join or key
to (and those others join or key to, and....) Ugh.
(In our case, all the SQLObjects for a given app reside in one
directory, so a really easy fix would be to have
classRegistry/needSet attempt to import those it doesn't have yet
from the directory of the class being called. But that's not a very
flexible alternative, so I'll ignore it. But if everyone else does
things that way too, then perhaps we can have needSet at least
attempt this... this gets back to my suggestion for multiple
classRegistry's as well.)
- Luke
|
