Yes, I definitely want to emit a DELETE statement. The Problem is that
calling master.delete() only gives an delete statement for the master
table. However, I need n querys: DELETE child1... , DELETE child2 and
so on.
On 8 Nov., 20:31, Michael Bayer mike...@zzzcomputing.com wrote:
On Nov 8,
On Nov 10, 2010, at 8:00 AM, Mene wrote:
Yes, I definitely want to emit a DELETE statement. The Problem is that
calling master.delete() only gives an delete statement for the master
table. However, I need n querys: DELETE child1... , DELETE child2 and
so on.
OK, so I think there's another
Hi Russell -
There's a lot going on here, so I'll point you to a few things.
1. the nested sets example, which also has the need to do update table set
x=x+1 in order to make room for new entries, thats in the distro at
examples/nested_sets/nested_sets.py .That example uses mapper
Thanks very much, Michael. I'll be looking into each point in detail.
Regarding the nested sets example, I've been scouring it since it is
much closer to my real use case which is hierarchical data. As tends
to happens more often than I like, I ended up finding out that I
basically re-invented
I have two tables, merchants and deals. The merchants table is
represented by Merchant and deals table by Deal.
Each merchant can have 0, 1, or many deals. Some of those deals will
be available, while others will be expired or coming soon or deleted.
Each deal belongs to exactly one merchant.
Hi Jonathan,
Rather than create a specific backref for each subtype of deal, why
not just continue with your basic 'deals' backref, then attach regular
python properties to your Merchant class which return just the desired
sub-deals.
Something like:
class Merchant(object):
...
@property
def
On Nov 10, 12:19 pm, Eric Ongerth ericonge...@gmail.com wrote:
Rather than create a specific backref for each subtype of deal, why
not just continue with your basic 'deals' backref, then attach regular
python properties to your Merchant class which return just the desired
sub-deals.
The twist is that I've spread out my tables and ORM classes across
several files. I've tried to keep it so that I don't have circular
dependencies. That means I've defined Merchant first, and then Deal
later, in separate files
To avoid problems with imports and dependencies you can pass
Good point, Sergey.
Here is the relevant documentation regarding mapping attributes to
selects:
http://www.sqlalchemy.org/docs/orm/mapper_config.html?highlight=arbitrary%20selects#sql-expressions-as-mapped-attributes
On Nov 10, 4:46 pm, Sergey V. sergey.volob...@gmail.com wrote:
The twist is
