Gabriel Jacobo wrote:
I have been checking on the issue of ActiveMapper, regarding its
use when classes with multiple inter-relations are involved. It
quickly became evident that if you intend to use ActiveMapper for a
case where the complexity of the classes goes a little beyond the
test case, the code fails, except you take extreme care with the
ordering of the classes...
This is true, and is a known issue. Thanks for taking a look at the
code, I really appreciate it!
Anyway...I think I´ve managed to modify ActiveMapper to lessen this
problem, maybe even solve it completely (at least to the extent of
my testing it works just fine). This modification is barely more
than a dirty hack, but it "just works". What I did was decouple the
table creation phase from the relations processing, which now must
be started "by hand", calling the function "connect_classes". Upon
calling this function, the system will check everyclass asociated
with ActiveMapperMeta, and will order them in the correct order for
everything to work fine.
This is certainly one way to do it (and was, in fact, the way that I
originally wrote ActiveMapper), but I think that there is a better
way to solve this, and allow relationship processing to happen
automatically. I don't think that the flaw is in the approach
necessarily, I think its just buggy code :)
In a recent discussion with someone else about this issue, I
suggested the following way to potentially fix the bugs *and* keep
the process automatic:
Currently the process_relationships function is called from within
the ActiveMapperMeta metaclass each time an ActiveMapper class is
defined.
Currently, lines 91 and 92 in ActiveMapper.py do the following:
for deferred_class in __deferred_classes__:
process_relationships(deferred_class, was_deferred=True)
This doesn't take into account various different orderings that the
classes may be specified in. In order to combat this problem, the
logic could be improved to keep trying to process relationships until
you cannot process anymore.
last_length = len(__deferred_classes__)
while len(__deferred_classes__) > 0:
for klass in __deferred_classes__:
process_relationships(klass, True)
if len(__deferred_classes__) == last_length:
# the number of deferred classes is the same as
# the last time through the loop, meaning that we
# were not able to resolve any new relationships
break
Give this a shot, and see what happens. I really don't like the
manual solution, as its far too invasive. Even if my suggestion
doesn't work, keep at it. I think that an automatic solution *can*
be reached.
Sorry I have not been keeping up with ActiveMapper as much as I would
like to. Things have been very busy for me lately, but I will get
back into the fold eventually.
--
Jonathan LaCour
http://cleverdevil.org
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
_______________________________________________
Sqlalchemy-users mailing list
Sqlalchemy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
