Hi all,
Using sqlalchemy 0.7.2 I created a couple of mixin classes (say Mixin)
to share columns declarations between model classes (say A and B).
Sometimes I have to create instances of type B initialized with the
values of an existing object of type A for the columns declared by
Mixin. I'd like
All the declarative examples have DeclarativeBase as the first/left base
class. Does it need to be? I've swapped it in several code locations and
experimented and it seems to be fine, but there's a lot going on with
declarative and I'm vaguely paranoid about messing it up subtly by altering
On Oct 17, 2011, at 11:38 AM, Russ wrote:
All the declarative examples have DeclarativeBase as the first/left base
class. Does it need to be? I've swapped it in several code locations and
experimented and it seems to be fine, but there's a lot going on with
declarative and I'm vaguely
Great - thanks for the response. This was causing me more brain ache than
I care to admit. My paranoia was rooted in the fact that the docs did seem
to go out of their way to put the Base first (without specifically saying
so) which is awkward as you say.
Much appreciated.
--
You received
Hello!
I've run into an odd error whilst using the history meta. I've got a
class which has two sub classes which define some additional columns.
The MainMeter class has a unique constraint on one of the colums.
When I have the history_meta create my history tables, the
trading_point_name column
My question is regarding sqlalchemy version 0.7.2.
Are there any limitations in using declarative or classic mapping
while using sqlalchemy?
My main concern is there any limitation of declarative mapping which
can put me in some situation where I am stuck with the tables it will
create?
Also
On Oct 17, 2011, at 5:40 AM, Robert Forkel wrote:
Hi all,
Using sqlalchemy 0.7.2 I created a couple of mixin classes (say Mixin)
to share columns declarations between model classes (say A and B).
Sometimes I have to create instances of type B initialized with the
values of an existing
ah the example has a bug, you're hitting a second part of the code there where
it fetches columns that are placed on a single table child class that are moved
up to the parent. Committing this now, here's a patch:
diff -r 653ae7f17379 examples/versioning/history_meta.py
---
On Oct 17, 2011, at 1:05 PM, Manav Goel wrote:
My question is regarding sqlalchemy version 0.7.2.
Are there any limitations in using declarative or classic mapping
while using sqlalchemy?
there's not, a declarative mapping is nothing more than a small organizing
layer on top of the
Thanks for the quick reply.
One question here, suppose I add column using Alter Table command and then in
class declaration the attribute. Will it see the newly added column then or not?
Concern is not issuing ALTER command by hand but is the class can see the newly
added column.
Regards,
The usual development model encouraged by SQLAlchemy is that class and table
definitions are a fixed element of your program, declared at the module level.
So typically, adding new columns means you're modifying the source code of
your app, then rerunning.
That said, if you add a column to
Hello,
I have a schema that includes these relationships:
class Airport(Base):
...
class Runway(Base):
...
airport = relationship(Airport, backref=backref(runways,
collection_class=set), lazy=joined, innerjoin=True)
...
class FlightEvent(Base):
...
runway =
On Oct 17, 2011, at 3:28 PM, Phil Vandry wrote:
- Whenever I fetch FlightEvents, I want to automatically fetch the
runways that may be referenced by the event, hence lazy=joined in
the runway = relationship. This relationship is an outer join because
an event may or may not reference a
Hi Michael,
going down the way you pointed I ran into what might be a small bug in
sqlalchemy: Trying to print out a RelationshipProperty I get
project_leader Traceback (most recent call last):
File stdin, line 3, in module
File
14 matches
Mail list logo
