Em Sunday 16 December 2007 09:46:09 Alberto Valverde escreveu: > > If the relations between those objects don't overlap, maybe. What I was > referring to was to closely related objects being handled by different > db (orm) sessions, for example, imagine a Post and Comment being in > different dbsessions and Comment having a "all, delete-orphan" cascade > rule (at the ORM level). My guess is that the Comment will crash when > being saved since the DBSession the comment is attached to doesn't know > about the Post since the Post is in another one. Again, this is all at > the ORM layer I'm referring to, not the DB.
Oh, for this type of interaction you are correct. I wouldn't think of splitting those thigs into different models since this doesn't make sense to me considering them as two different "projects". I believe that it also depends on the isolation level that the database allows you and if you are cacheing (and how aggressive this cache is?) or not on your ORM. > However, now that I think about it more closely, maybe all those > DBSessions will actually be the same one since they're thread-scoped? > I'm speculating now since I haven't actually checked this... I can't answer that as well... BUT, if you get different connections to the database, then you might have problems. > That was meant to be inside a single app's models/base.py. If I were to > share a DBSession among micro-apps, for any reason, I will probably > declare it once and import it in every micro-app or define a > tg.DBSession inside TG itself (like TG1 does) so it could be imported by > each one. I'd go with the latest approach. It looks like it is better for isolating apps. > The point I tried to make that having multiple DBSessions active in the > same request will probably need some good thought and have a good reason > for it behind since it will complicate things. Multiple DB's are a > another story and I *believe* a DBSession can handle them and even > provides mechanism for a two-phase commit to provide a transaction > accross multiple dbs, hence, as see it, a single DBSession is all that > is needed even for complicated cases. Hmmmm... This would be something worth testing (specially the two-phase commit). But with multiple DBs it is really hard to maintain referential integrity and so this becomes even harder. > I've never had the use-case for this though and have no experience. > Maybe someone who has can share some thoughts? Not me, yet. :-) -- Jorge Godoy <[EMAIL PROTECTED]> --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears Trunk" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~----------~----~----~----~------~----~------~--~---
