to intercept and act upon SQL strings, I would look into ConnectionProxy:
http://www.sqlalchemy.org/docs/reference/sqlalchemy/interfaces.html?highlight=connectionproxy#sqlalchemy.interfaces.ConnectionProxy
otherwise, if its a mediating layer to a DBAPI that is supported by SQLA, you
could make
Hi
Are there examples of using PostgreSQL's full-text search with
SQLAlchemy? I'm interested in any kind of information about that.
Thanks,
--
Eric Lemoine
Camptocamp France SAS
Savoie Technolac, BP 352
73377 Le Bourget du Lac, Cedex
Tel : 00 33 4 79 44 44 96
Mail :
On May 28, 2010, at 8:47 AM, Kent wrote:
Say I have this:
session().begin_nested()
try:
session.add(obj)
session.flush()
session.commit()
except:
session.rollback()
...
transaction.commit()
2 questions:
* I assume that the session.rollback() undoes the add(obj) -
we support the to_tsquery() syntax through the match() operator:
http://www.sqlalchemy.org/trac/browser/test/dialect/test_postgresql.py#L1748
On May 28, 2010, at 9:53 AM, Eric Lemoine wrote:
Hi
Are there examples of using PostgreSQL's full-text search with
SQLAlchemy? I'm interested in
* Is there a way besides session.commit() to free the savepoint
resource? Is there a way to provide the savepoint name, so I can use
the same name over? Lastly, if you aren't the expert, where would you
point me, zope group or TG group?
you could issue the SAVEPOINT instructions
Kent wrote:
[SNIP]
I'm fine with how SQLA is designed, it isn't really a SQLA
issue, I was
just appealing to you to see if you could think of a workaround I
believe the problem is in the framework tools we are using,
whether it
is Zope or TG. (I've posted to zope group now to see if
On Fri, May 28, 2010 at 3:12 PM, Michael Bayer mike...@zzzcomputing.com wrote:
we support the to_tsquery() syntax through the match() operator:
http://www.sqlalchemy.org/trac/browser/test/dialect/test_postgresql.py#L1748
Thank you very much.
--
Eric Lemoine
Camptocamp France SAS
Savoie
From a quick reading of the 'transaction' package source, it looks like
you should be able to create savepoints and roll them back something
like this:
savepoint = transaction.savepoint()
try:
# ...
except:
savepoint.rollback()
raise
Thanks for the interest in helping. I
Michael Bayer wrote:
How do people get around this? What's best practice in this area?
your test suite ideally wouldn't be tearing down and building up tables many times.
Correct ;-)
For an application where the testing is against a fixed set of tables (i.e.
not at all like SQLA's own
On May 27, 6:39 pm, Michael Bayer mike...@zzzcomputing.com wrote:
commit() releases the savepoint, if thats whats going on contextually. It
doesnt actually commit the outer transaction if you've last called
begin_nested().
In a SessionExtension, 'before_commit' is called for nested
Is the answer to second questoin session.transaction.nested?
On May 28, 1:24 pm, Kent k...@retailarchitects.com wrote:
On May 27, 6:39 pm, Michael Bayer mike...@zzzcomputing.com wrote:
commit() releases the savepoint, if thats whats going on contextually. It
doesnt actually commit the
On May 28, 2010, at 1:24 PM, Kent wrote:
On May 27, 6:39 pm, Michael Bayer mike...@zzzcomputing.com wrote:
commit() releases the savepoint, if thats whats going on contextually. It
doesnt actually commit the outer transaction if you've last called
begin_nested().
In a
On 5/28/2010 10:08 AM, Michael Bayer wrote:
Is the pattern that you want to keep re-issuing a savepoint repeatedly
using the same name ? Does that have some different usage of resources
versus issuing/closing distinct savepoints with different names ?
As an aside, since oracle apparently has
This is the ORM affecting 124K statements so must be a very large data persist
(it seems like a persist heavy operation, i see 287K objects total treated as
part of units of work).
It seems like you are calling commit() a very large number of times. So the
most obvious enhancement would be
On Fri, May 28, 2010 at 3:48 PM, Michael Bayer mike...@zzzcomputing.comwrote:
This is the ORM affecting 124K statements so must be a very large data
persist (it seems like a persist heavy operation, i see 287K objects total
treated as part of units of work).
It seems like you are calling
On May 28, 2010, at 5:18 PM, Jason Baker wrote:
On Fri, May 28, 2010 at 3:48 PM, Michael Bayer mike...@zzzcomputing.com
wrote:
This is the ORM affecting 124K statements so must be a very large data
persist (it seems like a persist heavy operation, i see 287K objects total
treated as
16 matches
Mail list logo
