On 8/20/07, Michael Bayer [EMAIL PROTECTED] wrote:
I'd be curious though if you could play around a little with
the approach I just suggested to see if its at all workable ?
After quite a bit of head-scratching I think I've got the hang of
this. Here's what I'm doing using the basic_tree.py
Hi!
I'm having a bit of an issue where a table with a set schema is
autoloaded. The table has a self-referential foreign key (it's a tree
structure), which is having its referenced table loaded without a
schema name. This, it seems, causes SQLAlchemy to stop dead when
attempting to load objects
caffecoder napisał(a):
Hello.
I have pylons 0.96 (SVN) and current SQLAlchemy (0.3), and I have bug
that
doesn't exist earlier.
My connection code:
code
import sqlalchemy.mods.threadlocal
from sqlalchemy import DynamicMetaData, objectstore
metadata = DynamicMetaData( case_sensitive =
On 8/31/07, Michael Bayer [EMAIL PROTECTED] wrote:
however in most cases keeping a low pool_recycle should take care of
most common issues in this area...
What it doesn't handle is if the database server is restarted. That
doesn't happen very often with reliable database servers nowadays but
On Aug 29, 8:16 am, Mike Orr [EMAIL PROTECTED] wrote:
I've been getting a similar but not identical error after upgrading to
SQLAlchemy 0.4, and somebody else on the list also mentioned this
recently. I don't have the traceback but it was the error for
exceeding the 'max_overflow' number of
Orest Kozyar wrote:
class user(object):
__metaclass__ = EntitySingleton
def __init__(self, firstname, lastname):
pass
class pet(object):
__metaclass__ = EntitySingleton
def __init__(self, owner, species):
pass
I changed __call__
I've started getting this same overflow error after upgrading to the
latest beta4, I don't recall having the problem with beta3 but during
beta3 I used Session.mapper and now I'm using plain mapper. Not sure
if that affects it at all though.
I'd love to know why all of a sudden, there's
all connections in DBAPI are transactional. theres no begin()
method, only commit() and rollback(). some DBAPis support an
autocommit flag but this is not standardized. so SA has not much
choice but to issue its own autocommit behavior, which could be
expanded to detect CREATE
Hi,
What it doesn't handle is if the database server is restarted. That
doesn't happen very often with reliable database servers nowadays but
it is possible.
Yes, this is something of a problem for long-running apps that used
pooled database connections.
I did some work with Mike a few
On Aug 31, 2007, at 4:33 PM, Michael Bayer wrote:
I've started getting this same overflow error after upgrading to the
latest beta4, I don't recall having the problem with beta3 but during
beta3 I used Session.mapper and now I'm using plain mapper. Not sure
if that affects it at all
On Aug 31, 1:33 pm, Michael Bayer [EMAIL PROTECTED] wrote:
I dont think theres a connection pooling issue; its just that the
Session being remove()'d still references a checked out connection,
which has been fixed in the latest trunk. please issue Session.close
() before Session.remove() as
Alexandre Conrad wrote:
Dear SQLAlchemy users,
I am pleased to announce the first release of FormAlchemy !
I use reflected tables and I wanted to check out FormAlchemy as a
candidate for generating quick forms for maintaining my tables through
the web.
Here is my little test (using the code
12 matches
Mail list logo
