On Feb 2, 2007, at 2:14 PM, svilen wrote:
> of course, topological sort is a sort, but in order of it to work, the > graph should not have cycles. Which are cut by use_alter's and > post_updates, on foreign keys and relations. > > well, in our case all edges have cost of 1, except inheritance-related > primary-key-joins which have cost of infinity, so they become > uncuttable. > Duplicate edges do matter as they increase the total cost. > Thus min cut is a cut with mininal cost, which is the number of edges > cut. > yeah im no mathematician but i dont think you can use just part of a theory thats designed for flow diagrams with some totally different kind of diagram. we dont have a "capacity" concept here, nor "cost", nor the "source" and "sink" endpoints described. the pages linked from wikipedia have the "flow network problem" and the "feedback arc" problems in completely different, non-referencing categories. > i am trying to automaticaly add the relations' post_update, given a > set of classes and their relations. if you make usage of the results of _find_cycles(), its already there. take the edges indicated in the cycle, remove one, then sort again. its an expensive operation, but as the wikipedia article states, its an "APX Hard" problem to find the minimal set of edges to be removed. > > My conclusion from the source code, is that current > object/mappers-based flush() does not handle the concrete-inheritance > in a different way than table-inheritance, while IMO they should > differ as they touch different set of tables. possibly... it would involve changing the definition of _get_noninheriting_mappers() to return various concrete mappers as separate. the base of a mapper inheritance hierarchy is currently treated as a single node in the dependency tree. these are all things i will address when i begin to make concrete inheritance work for all reasonable cases. noting that, i have spent almost no time at all on supporting concrete patterns at this point (also, nobody has really complained). > > which in a way confirms your saying about flush() would be better > based on tables/foreign keys than obj/mappers. possibly, but thats nothing that will happen anytime soon unless someone gives me a full time salary working on SA :). its not as easy as it sounds since we cant just compile a whole set of SQL statements together - there are still data synchronization operations, which are mapper specific, that must occur between each pair of dependencies. so there are still inter-mapper dependencies that may in some cases be independent of the dependencies of tables or rows. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
