yeah, sorry about this issue, it is coming up more and more often.   i might 
have to think of something (which is known to happen fairly often)


On Jan 28, 2014, at 12:27 PM, Erkan Özgür Yılmaz <[email protected]> wrote:

> 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.

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

Reply via email to