Hi Michael,
According to your comment, I've updated the
Task.update_status_with_dependencies() method to count the previously
removed dependent tasks with a temp buffer list and create a new list of
tasks from self.depends and the self._previously_removed_dependent_tasks
buffer and it seems that it is solving my issue for now:
...
def update_status_with_dependent_statuses(self, removing=None):
logger.debug('inside update_status_with_dependent_statuses')
if removing:
self._previously_removed_dependent_tasks.append(removing)
still_in_depends_list = []
for dep in self.depends:
if dep not in self._previously_removed_dependent_tasks:
still_in_depends_list.append(dep)
#if not self.depends:
if not still_in_depends_list:
self.status = 'RTS'
else:
logger.debug('self.depends : %s' % self.depends)
...
@event.listens_for(Task.task_depends_to, 'remove', propagate=True)
def removed_a_dependency(task, task_dependent, initiator):
task.update_status_with_dependent_statuses(
removing=task_dependent.to_node
)
I've read a G+ post of Van Rossum, and moving to PyPy seems not going to
happen in the near future if not at all. Anyway thank you for your ever
speedy answer.
Thanks Mike,
regards
E.Ozgur Yilmaz
eoyilmaz.blogspot.com
On Tue, Jan 28, 2014 at 7:10 PM, Michael Bayer <[email protected]>wrote:
>
> On Jan 28, 2014, at 11:27 AM, Erkan Özgür Yılmaz <[email protected]>
> wrote:
>
> > Hi everybody,
> >
> > I'm trying to use Association Proxy in one of my classes relation to
> itself. I've got a Task class and Tasks can be dependent to each other, and
> I've also wanted to store the dependency type ('start-to-start',
> 'start-to-end' etc.), so AssociationProxy was the way I've gone. Any way my
> problem is with events.
> >
> > So, TaskC depends both to TaskA and TaskB. When I set taskC.depends to
> [] the remove event successfully triggered, and the
> Task.update_status_with_dependent_statuses() method is run. And at the end
> taskC.depends list is [].
> >
> > The problem is; even when the second event triggered I still see [TaskA,
> TaskB] in task.depends, where it should at least be [TaskB] in second run.
> Therefore the update_status_with_dependent_statuses() method always sees
> some elements in self.depends and is not able to set the status to RTS.
> >
> > Is that making sense? Am I missing something in the documentation?
>
> the documentation is still missing a pretty important note which is that
> the attribute events fire off *before* the actual mutation takes place. So
> in your event, “self.depends” is still populated.
>
> We haven’t produced a decent solution to the “no events *after* the fact”
> issue; to add event dispatchers for “after” mutation corresponding to every
> “before” mutation would add a significant amount of function calls to every
> collection mutation and attribute set operation, and as long as cPython is
> still the standard interpreter (as opposed to Pypy, which solves this issue
> entirely) the area of attribute mutation remains a major performance
> bottleneck even without more function calls being added. We’d have to
> figure out a way to organize the (already pretty dense) code to support
> event handlers on both sides without adding major new overhead.
>
> For the time being you’d need to have your event handler be sensitive to
> the fact that the operation is a “remove”, and to anticipate the state that
> you’re responding towards. That or, create your own collection classes -
> such as subclassing the collection implementation used by the “depends”
> association proxy.
>
>
>
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sqlalchemy.
For more options, visit https://groups.google.com/groups/opt_out.
