On Jun 22, 2008, at 5:38 AM, Marin wrote:
> > Thx for the info. I took a short look at the code yesterday, and I > can't understand why do you use the _organize_as_tree function. The > ordered list of nodes that the topological sort returned should be > enough for the flush. Maybe I am missing the idea behind the code (but > that is OK since this is the first time I took a glimpse at the code) > >> the tree-based structure is mostly a historical artifact at this point. The original sort generated a tree directly, and later the linear topological algorithm was dropped in; but the tree structure allows as many rows as possible to be grouped together, so that many rows could be "batched" together...so the "organize_as_tree" function was added on top of the linear algorithm (you can see how its been made to be optional). In theory, the "batching" would allow more efficient calls like executemany() to be used, but long ago we abandoned that concept since we can't get cursor.lastrowid back for individual rows in an executemany(). It was only recently that the "tree" part of the sort was removed from the per-table part of unitofwork. At that same time, I tried removing it from the per-row sort, but some tests started failing. I wasn't able to determine if it was some artifact of the tree-structure or an error with my re-implementation that caused the failures. So the trac ticket basically says, "try it again". 0.5 has already simplified the flush process a little bit towards that direction. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
