Sorry to top-post, but this is one of the reasons I wrote mortar_rdb,
writing offline from memory, the url is:
http://packages.python.org/mortar_rdb.
Anyway, have a read of the docs, it solves the
Base-shared-across-packages problem as well as providing session and
transaction management.
It has a schema-management aspect too, but I regret that now. Thankfully
it's optional :-)
cheers,
Chris
On 16/12/2011 08:33, Robert Forkel wrote:
On the other hand, I'm not doing anything in my custom cls passed to
declarative_base which could not be done in a mixin class [1].
[1]
http://www.sqlalchemy.org/docs/orm/extensions/declarative.html#mixin-and-custom-base-classes
On Fri, Dec 16, 2011 at 9:21 AM, Robert Forkel<[email protected]> wrote:
sqlahelpers tried to do exactly this; but this approach makes it
impossible to provide arguments for the construction of the
declarative base [1]. I moved away from sqlahelpers because I wanted
to supply my own base class.
regards,
robert
[1]
http://www.sqlalchemy.org/docs/05/reference/ext/declarative.html#sqlalchemy.ext.declarative.declarative_base
On Fri, Dec 16, 2011 at 9:12 AM, Chris McDonough<[email protected]> wrote:
On Fri, 2011-12-16 at 02:02 +0100, Viktor Nagy wrote:
hi,
I'm no SQLAlchemy expert but out of curiosity, why can't there be a
"master" package that all the apps depend on that declares a Base that
all the other packages depend on and import from?
- C
I'm stuck and sweating with a "should be simple, so common" problem
related sqlalchemy and portable pyramid app development.
I would like bind together several apps using config.include.
All these apps use their own DBSession and Base declarations. The
DBSession shouldn't cause any troubles as scoped session is used
everywhere, but this is not true about the Base declarations.
If I don't want to import the Base of one of my apps (it's not
feasible in my case anyway), then I have to move every already
defined table from other models' metadata to this Base.metadata,
otherwise SQLAlchemy can not find related tables as they are contained
within separate metadatas.
Moreover, even when I come up with some really dirty solution and
manage to run the pserve, the populate script needs a different
approach just like writing tests, and it seems to me that in every
situation I should invent new approaches, and I'm running out of
ideas. :)
I guess that overcoming such situations should be a common task, so I
would be glad if you would share your experiences with me.
thanks,
Viktor
--
You received this message because you are subscribed to the Google
Groups "pylons-discuss" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to pylons-discuss
[email protected].
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en.
--
You received this message because you are subscribed to the Google Groups
"pylons-discuss" 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/pylons-discuss?hl=en.
--
Simplistix - Content Management, Batch Processing & Python Consulting
- http://www.simplistix.co.uk
--
You received this message because you are subscribed to the Google Groups
"pylons-discuss" 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/pylons-discuss?hl=en.
