--------- replacing __init__(...) - i see that some effort is taken to keep the original signature. But the result wont be debuggable IMO.
cant it be some_init(*a,**kw) doing whatever( *a,**kw) and/or calling original_init(*a,**kw) ? whats inside is not changing as sequence/logic anyway... OR, maybe fix/hack with the co_filename and co_firstlineno code-attributes or whatever so inspect.getsource( damnedclass.__init__) "works"... --------- anyway. i have some obj.pre_save() hook-method that is called just before session.save_or_update( obj), to do last-point validations and/or setup of timestamp-like fields. There's an idea/ need to replace that with mapper_extension.before_insert() but i'm not sure if these are going to be equivalent flow-wise. To me, save() is much higher level thing than before_insert - nothing has happened yet, and an exception thrown in wanna-be save() isnt going to cancel anything big... while in before_insert() is going to force a rollback, no? i.e. undo stuff that IS already done to the db. Also pulling things into flush isnt possible in before_insert() - not that i'm doing such things but who knows who's gonna use that hook for what.. maybe i have to split into 2 levels? one for save() and one for before_insert? right now the latter is needed only for relations and similar associated things, pulled by some save(), to be also setup correctly. Any specific hook for those i can use? or maybe i should have both... now, why i got here at all... in order to call the pre_save() i am duplicating the save() behaviour to setup a _state if an instance doesnt have one. do i really need that? looks like i may want to hook before session.save() calls the session._save_impl(), when the state is already there... which is only possible in the branch now. ok i'll do my own _state_setup() for backward compatibility -------- sql.visitors.ClauseVisitor: - seems the place/order of actual visitation has changed... before order was children then parents (post-walk, depth first), now it jumps straight onto parent (e.g. visit_binary) before any child (pre-walk ?). Isn't quite a time to fix this visiting pattern, allowing more flexibility? As i see, the iterate_depthfirst is what i need, and i hacked module-level iterate to point to that, but that isn't a good way - i need it temporarily. IMO the visitors.traverse() should have one more argument iterator_func, and that to be passed whatever the Visitor's .iterate is, instead of using hardcoded module-level iterate. - those name[6:] things... mmh. --------- hey, i start to notice some pattern ... where i use something sa-internal, the more quick/hackish/inflexible it has been done, the more (frequently) it changes - so i have many many versions of ways of using it. do u want some statistix which items got biggest number of versions so far ? (:-) ---------- btw the concrete-polymorphism errors come at v4371, and branch has them too. Next thing i'll be looking at. is the branch going to be merged any soon or not really? ciao svil --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
