> they don't build up magically by default (though the cascade parameter >> allows the same flexibility as the one present in your backend) but given >> that all the six "important" events are available and fired accordingly, >> you can hook up whatever business logic you like. >> >> > > That answer is too vague for me... Can you elaborate? > What cascade-parameter? What do you mean by "your backend"? What "six > important" event? >
See "ondelete" here<http://web2py.com/books/default/chapter/29/06#Record-representation>, as well as the section on callbacks<http://web2py.com/books/default/chapter/29/06#before-and-after-callbacks> . > SQLA's ORM-class-instances are reused across requests. > Web2py's DAL instances are not. > If I wanted to emulate a SQLA-ORM in web2py, I would have to put it all in > custom-modules, that would persist class-instances in memory, and do a lot > of these invalidation/dirty-chacking stuff myself. I think a way around > this might be to keep the DAL-layer separate, in that instances of > ORM-classes may persist in memory across requests in a custom module that > is not reloaded, but that they would be dynamically re-linked to DAL > instances that would still be re-generated for each request by executing > the models as usual. > Not quite sure what you mean here. Are you saying in SA, you would keep a database transaction open across multiple HTTP requests? Can you show an example of SA code that would be inconsistent with web2py's execution model? Anthony -- --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
