|
From: Bud P. B. <bu...@si...> - 2003-04-22 16:43:45
|
Thanks, Luke, for the explanation and insight.
Hmmmm.. So what about a not overly elegant solution to createTable
with foreign keys that works for the time being. Something like:
In Col.py, _extraSQL:
if self.foreignKey:
if type(self.foreignKey) == type([]):
foreignTableSQLName = foreingKey[1]
else:
foreignTableSQLName = SQLNameFromClassName(self.foreignKey)
result.append('REFERENCES %s') % foreignTableSQLName
If the table name is automatically derived from the class name, the
foreignKey keyword argument is used as usual. If not, foreignKey
takes a list where the second element is the table name that was
(redundantly) already given in _table.
SQLNameFromClassName is a placeholder for the real conversion routine
that I didn't find quickly enough...
As announced before, not elegant (mainly because of redundancy and
probably difficult to use), but it should work...
what do you think?
On Tue, 22 Apr 2003 10:52:00 -0500
Luke Opperman <lu...@me...> wrote:
>
> > 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
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> sqlobject-discuss mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss
>
/-----------------------------------------------------------------
| Bud P. Bruegger, Ph.D.
| Sistema (www.sistema.it)
| Via U. Bassi, 54
| 58100 Grosseto, Italy
| +39-0564-411682 (voice and fax)
\-----------------------------------------------------------------
|
