I think it's OK to add __abstract__ to those mixins, in this case it
seems like the (pretty complicated) class graph is adding up to
something that causes declarative to see AbstractCar as mapped class
thus a "car" table is added. Adding __abstract__ to AbstractCoupe seems
to resolve.
On
I implemented the changes you suggested, but I am running into errors with
some polymorphic relations. Using a different theme, here is an example:
class AbstractVehicle(object):
__tablename__ = "vehicles"
id = Column(Integer, primary_key=True)
name = Column(String, nullable=False)
On 06/27/2016 12:46 PM, davepuffin via sqlalchemy wrote:
I've checked netstat and there are only 15 mysql connections (status is
still reporting the same):
Pool size: 20 Connections in pool: 19 Current Overflow: -36 Current
Checked out connections: -35
On our other servers, the number of
I've checked netstat and there are only 15 mysql connections (status is
still reporting the same):
Pool size: 20 Connections in pool: 19 Current Overflow: -36 Current
Checked out connections: -35
On our other servers, the number of connections (from netstat) matches up
with the pool status as
Ah, thanks for the tip, the info fields work nicely as well.
Have a nice day,
On Monday, June 27, 2016 at 4:09:54 PM UTC+2, Mike Bayer wrote:
>
>
> Hi Martijn -
>
> Sorry I missed this post.Your solution is pretty good. For the
> setattr() stuff, both Connection and Session have an .info
Well it is possible QueuePool doesn't do the right thing under eventlet,
though we use it a lot w/ eventlet in Openstack and I've tested it
myself quite a bit. Have not peeked at this number, however.
You'd need to produce for me a self contained test suite that
illustrates this behavior
Thanks for the reply :)
I think you're right in that it must be threading related somehow, but it
looks like all the monkeypatching has been applied correctly. If I examine
the locking object used in the pool I get:
>>> type(engine.pool._overflow_lock)
On Mon, Jun 27, 2016 at 4:21 PM, Mike
On 06/27/2016 10:48 AM, davepuffin via sqlalchemy wrote:
Hi
QueuePool.status() is returning some odd looking negative values from
one of our production applications.
engine.pool.status()
'Pool size: 20 Connections in pool: 19 Current Overflow: -36 Current
Checked out connections: -35'
The
Hi
QueuePool.status() is returning some odd looking negative values from one
of our production applications.
>>> engine.pool.status()
'Pool size: 20 Connections in pool: 19 Current Overflow: -36 Current
Checked out connections: -35'
The pool was initialised with: pool_size=20,
Not really sure, that URL itself won't allow a psycopg2 connection to
even occur. The error means that the construct is trying to be
generated as a string, like in a print statement. But 1.1 has a new
feature that allows default stringification of pg.ARRAY and other
constructs to actually
not currently, and we don't actually spend much time working on the
Firebird dialect (would love if someone could come take it over). Your
best bet would be working with custom compilation rules described in
http://docs.sqlalchemy.org/en/latest/core/compiler.html .
On 06/27/2016 07:47 AM,
Hi Martijn -
Sorry I missed this post.Your solution is pretty good. For the
setattr() stuff, both Connection and Session have an .info attribute
which is a dictionary you can use for memoizations.
On 06/27/2016 03:02 AM, Martijn van Oosterhout wrote:
On Tuesday, June 21, 2016 at
When trying out 1.1.0b1 (to look at the new events) I got the $SUBJECT
error from our test cases.
I'm not sure what exactly is going on, because when I run the script below
line-by-line in the django shell, it breaks, but if I run it from the
command-line it works. But that's probably more to
Is there a way to construct a query "UPDATE OR INSERT" for firebird like
Postgres "INSERT...ON CONFLICT (Upsert)"
(http://docs.sqlalchemy.org/en/latest/dialects/postgresql.html#insert-on-conflict-upsert)?
Firebird docs
http://www.firebirdsql.org/refdocs/langrefupd25-update-or-insert.html
--
On Thursday, June 23, 2016 at 11:22:32 PM UTC+2, Chung wrote:
>
> Ah thanks Mike; that makes sense.
>
> What we have is actually hundreds of different databases with roughly the
> same schema, with new databases getting created all the time live. The
> table schemas for each database are also
On Tuesday, June 21, 2016 at 11:25:36 PM UTC+2, Martijn van Oosterhout
wrote:
>
> Hi,
>
> In an effort to find the bottlenecks in our system we'd like to collect
> statistics about which queries take a long time, or return a lot of rows,
> or paths which are triggering lots of queries.
>
>
16 matches
Mail list logo
