On 24/01/2010 16:57, werner wrote:
...
Next thing is to make _get_translation reusable for different tables.
I got it down to this:
def _do_translation(bInstance, tTable, fCrit, cLang, dLang):
try:
x =
-Original Message-
From: sqlalchemy@googlegroups.com
[mailto:sqlalch...@googlegroups.com] On Behalf Of werner
Sent: 25 January 2010 13:37
To: sqlalchemy@googlegroups.com
Subject: Re: [sqlalchemy] dynamic_loader
On 24/01/2010 16:57, werner wrote:
...
Next thing is to make
I have this definition in my upgrade script using migrate
meta = MetaData(migrate_engine)
DeclarativeBase = declarative_base(metadata=meta)
maker = sessionmaker(autoflush=True, autocommit=False,
extension=ZopeTransactionExtension())
DBSession = scoped_session(maker)
Simon,
On 25/01/2010 15:18, King Simon-NFHD78 wrote:
...
I hope that helps,
Yes, that did help a lot.
This is my custom property class.
class TranslationProperty(object):
Returns a query enabled property
def __init__(self, tTable=None, fCol=None, cLang=None, dLang=None):
Todd Blanchard wrote:
I have this definition in my upgrade script using migrate
meta = MetaData(migrate_engine)
DeclarativeBase = declarative_base(metadata=meta)
maker = sessionmaker(autoflush=True, autocommit=False,
extension=ZopeTransactionExtension())
DBSession =
Hello all!
I have a question about handling errors in SQLAlchemy.
Before I used SQLAlchemy I used to rigorously check for all errors
when executing queries, like:
status = db.query(INSERT INTO users ...)
if !status:
handle_insert_error()
But now when I have switched to SQLAlchemy I write
Ugh. Then I just don't get the point - the only reason to use inheritance is
to avoid defining all the fields twice (and I have a bunch of methods - but
still).
I might as well stick with the class decorators approach (which is working
really well for me).
On Jan 25, 2010, at 1:10 PM,
On Jan 25, 2010, at 9:13 PM, Todd Blanchard wrote:
Ugh. Then I just don't get the point - the only reason to use inheritance is
to avoid defining all the fields twice (and I have a bunch of methods - but
still).
I might as well stick with the class decorators approach (which is working
On Jan 25, 3:08 pm, Michael Bayer mike...@zzzcomputing.com wrote:
jpeck wrote:
Depending on your database, you may have a function-style row
constructor that does what you want. For example, PostgreSQL treats (a,
b) and ROW(a, b) as equivalent. If this works for you, then I think you
