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?
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...
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. ;-)
--
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
-~----------~----~----~----~------~----~------~--~---
