On 28/02/2012 19:56, lars van gemerden wrote:
I can see that being true in the general case, and at some point i
will start working with a serious database, but at the moment i am
working on a prototype (in which db persistance is maybe a quarter of
the work), still have a long list of items to
On Tue, Feb 28, 2012 at 5:20 PM, Eric Lemoine
eric.lemo...@camptocamp.com wrote:
On Tue, Feb 28, 2012 at 4:46 PM, Michael Bayer mike...@zzzcomputing.com
wrote:
wowwell yeah, though putting it in the column_info is not how i'd want
to do that. I'd like to change the API for 0.8.
I suspect this doesn't interest you so much, and no offense taken if not,
but have you ever considered supporting the idea of a half
merge/save-update cascade for many to many relationships?
The use case is where I want to merge/save-update to the secondary table
only (collection status), but
Ok I'm assuming geometrycolumn doesn't go into a Table it gets stuck on a
declarative class, Table wouldn't accept it. I would modify this using the
declarative reflection recipe, which sets up everything that gets sent to
mapper(). Iterate through the reflected table columns and generate
I get what that would do for merge and might not be a big deal, what would it
do for save-update?
Sent from my iPhone
On Feb 29, 2012, at 8:55 AM, Kent jkentbo...@gmail.com wrote:
I suspect this doesn't interest you so much, and no offense taken if not, but
have you ever considered
I hadn't really thought the save-update through, my real interest was
regarding merge. For save-update it may not make as much sense.
On 2/29/2012 10:55 AM, Michael Bayer wrote:
I get what that would do for merge and might not be a big deal, what
would it do for save-update?
Sent from my
On Wed, Feb 29, 2012 at 4:52 PM, Michael Bayer mike...@zzzcomputing.com wrote:
Ok I'm assuming geometrycolumn doesn't go into a Table it gets stuck on a
declarative class, Table wouldn't accept it.
I think that's correct. We use GeometryExtensionColumn in a Table.
GeometryExtensionColumn is a
On Wed, Feb 29, 2012 at 4:52 PM, Michael Bayer mike...@zzzcomputing.com wrote:
Ok I'm assuming geometrycolumn doesn't go into a Table it gets stuck on a
declarative class, Table wouldn't accept it. I would modify this using the
declarative reflection recipe, which sets up everything that
How would I do a with x as (...) select ... in sqlalchemy orm-ish?
Chris
--
Simplistix - Content Management, Batch Processing Python Consulting
- http://www.simplistix.co.uk
--
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to
rough road ahead on that one for now, we have a @compiles recipe so far at
http://www.sqlalchemy.org/trac/attachment/ticket/1859/cte_demo.py . You'd need
to open it up to make it more generic than just WITH RECURSIVE.
On Feb 29, 2012, at 11:38 AM, Chris Withers wrote:
How would I do a with
Hi:
As the latest SQLAlchemy already supports postgreSQL dialect and connection
pools, I wonder if anyone can share some experience on what would be the
benefits of using psycopg2 (postgresql+psycopg2) and its connection pool
over SQLAlchemy's ?
thanks
Cheng Lio
--
You received this message
Hi!
My problem: I have a base class that maps a 'title' attribute. In a
subclass I want to turn that title into a descriptor (just like the
'hybrid_property' examples really).
I think I want to avoid mapping the attribute as '_title' in the base
class. Not sure I like the added complexity.
On Feb 29, 2012, at 2:23 PM, Daniel Nouri wrote:
Hi!
My problem: I have a base class that maps a 'title' attribute. In a
subclass I want to turn that title into a descriptor (just like the
'hybrid_property' examples really).
I think I want to avoid mapping the attribute as '_title' in
13 matches
Mail list logo
