[EMAIL PROTECTED] wrote: > > one thing that is a concern > for me, however, is that the > dependency graph seems to > keep on growing even though > only a single C1/C2 pair is > being updated. (i've included > that task dump output below). >
OK, what you are seeing there, specifically with the lines like this: | |-UOWTaskElement(-1222743124): C2(-1222763092) (listonly) | |-UOWTaskElement(-1222743092): C2(-1222763508) (listonly) is the "t1" attribute on each C2 object being included in the processing cycle. You can probably see that the one with the "save" corresponds to the entry being saved. the full list of them are going to be sent to the method process_dependencies in properties.py. This is the method that synchronizes the values of foreign keys between dependent objects and also handles the deletion of child items marked "private". For this save operation in particular, all of those "listonly" objects are being passed over without much really happening to them. It is not clear to me, without running this code and probably uncommenting a print statement on line 336 of objectstore.py, why these dependent objects are getting inserted into the commit graph when nothing really has to change with them, however the unit of work is definitely liberal when determining what gets put in that graph; part of what I want to work on is slowly tuning that graph to be more streamlined. So they are adding some overhead to the commit, but not a lot. They are definitely not being manifest as any additional SQL or anything like that. While I will look into further improving the commit to only hit objects that need to be hit, there is always going to be overhead assocaited with each in-memory mapped object. If you are trying to do something that really has to scale up a lot, you might want to drop into straight SQL. Also, Im not sure why you are doing objectstore.commit() within a loop like that, why not do the commit after your loop has finished (thats how it was meant to be used) ? also curious why you have a separate step for generating primary keys, since that behavior is built-in via sequences or "defaults". - mike ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ Sqlalchemy-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
