On Apr 30, 2008, at 8:50 AM, [EMAIL PROTECTED] wrote:
> > --------- > 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"... are we talking about the __init__ placed on instances ? how is that not debuggable ? I know that pdb is forced to illustrate one line in the trace as being part of a "string" but thats not such a big deal. > 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.. you should use a SessionExtension for this hook. It'll give you a pre- flush() which I think it what you're looking for. flushes do roll back still. Some DB's can't continue after various kinds of constraint violations occur (Postgres after a primary key violation comes to mind). Although using SAVEPOINTs, flushes can be made to be atomic within a larger transaction (and we're going to have great support for that). > > 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 the ORM ensures that instances always have a _state. I think the primary entry point on that is via the instrumented __init__() method as well as the on-load hooks. I dont know why you'd need to set up a _state even in 0.4, that's an internal detail which the ORM handles (unless you're blowing away SA's __init__ decorator, which would be bad). > > 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. I just added traverse_depthfirst() for you. In reality, I dont need iterate/traverse_depthfirst() at all and I was almost going to just remove them the other day, so maybe you should just maintain these on your end if you need a very specific traversal. As far as the callable, thats nice for a general use API but thats not really what "visitors" is right now - I dont need to have all of my ORM functions piecing together iterate + traversal functions since for my needs the order of iteration is never important. When I need to copy and modify the structure, I have cloned_traverse() and replacement_traverse() which have very specific traversal orders based on what they need to do. > > - those name[6:] things... mmh. there was a metaclass trick I was working on there but it ran into problems. so that approach there is temporary until something class- level can be worked out. > > 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 ? (:-) heres an idea - dont write your application to sqlalchemy internals ! of course the more hacky ones are going to change more frequently since we're still figuring out the best way to do them (thats why they're...hacky !) I cant think of any code even in 0.5's progress that isnt subject to being massively changed yet again (for example, sync.py and dependency.py are very solid now, and aren't changing at all...but what if someday we reduce the overall complexity of the flush process such that they aren't needed ? its possible....) > > 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? its going to merge extremely soon. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
