Jorge Godoy wrote: > Em Sunday 16 December 2007 08:24:35 Alberto Valverde escreveu: >> That looks like begging for trouble... I think you should use the same >> mapper instance on all models and the same DBSession. > > But shouldn't this work? I don't see why... Multiple sessions on the > database, but every object in the model will know to which context / session > it is attached to and the RDBMS should be able to handle things if it was > modeled correctly (modeled on the RDBMS here != modeled on Python). > > This should, actually, allow for more concurrency, shouldn't it?
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. 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... > > Or you are afraid with different session / context for managing common things > like Identity, for example? > >> What I usually do when splitting my models in different modules is to do >> all SA imports, scoped_session creation and mapper "instantiation" in >> models/base.py and then in every model submoudle I do "from base import >> *" to get all the symbols. It's in this base.py where I also define >> custom TypeDecorators, a MappedClass base class every model subclass >> derives from (with some useful methods like a SO-like set()) and any >> other helper I want available at all model submodules. > > This prevent micro-apps from working. Unless all micro-apps are agnostic of > these values and instantiated on the application, but then you'd have to have > knowledge about every class inside the micro-app's model... 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. 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. I've never had the use-case for this though and have no experience. Maybe someone who has can share some thoughts? > > What I mean, in a supermarket software: > > - you can have a package for accounting > - you can have a package for POSs > - you can have a package for HR > - you can have a package for storage > - you can have a package for suppliers > - you can have a package for clients > - you can have a package for business partners within the store > - ... > > If you have to have all of these on each and every application (HR, > accounting, clients and suppliers are generic enough to be reused several > times!) or if you have to know exactly the classes inside those packages you > loose productivity. > > What I think would be ideal is creating all those packages independently > (e.g. > tg-admin create pos, tg-admin create suppliers, ...) and working with them > independently. > > Then, importing what you need from the model to implement the logic on the > rest of the application or to glue everything together. > > Finally, importing the controllers you need from these micro-apps (not so > micro, I know...) to implement some extra functionality. This is possible if > using, e.g., Genshi because you can specify the master template very easily > to the newly imported package and it will reuse it on its templates (I do > that and it works perfectly!). > >> In models/__init__.py I just import the external API from the model I >> want available to the rest of the app to keep Demeter [1] happy and have >> some model internal refactoring freedom (note that this avoids any >> circular dependencies). Usually the only things I "export" to the >> controllers are the DBSession and first-class business objects and *no* >> SA querying functions (and_, or_, desc, etc..), I try my best to hide >> queries inside classmethods so the controllers access a well-defined API >> that makes sense to the app, this is to reduce coupling. > > I do almost the same with SO. And I also have lots of logic inside the > database as stored procedures, function, triggers and views. I try having > the minimum amount of logic that requires cycling through records on Python > side because this is really a show stopper with regards to performance and > the RDBMS can do that very fast and just return what is needed. > >> [1] http://en.wikipedia.org/wiki/Law_of_Demeter > > Smart law. ;-) > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
