, test it on
> a staging database first, then run in production.
>
> then again, the ALTER will probably be extremely quick if you can in
> fact pause the load for a few minutes, since you are defaulting to
> NULL.
>
> On Tue, Jan 16, 2018 at 3:42 PM, George V. Reilly
Twice recently, on two different PostgreSQL 9.5 databases hosted at Amazon
RDS, we've been unable to apply Alembic migrations. We have successfully
run dozens of Alembic migrations in the past against one of these databases
but those were quieter times for us. As far as I can tell, it's because
On Saturday, September 19, 2015 at 8:14:31 AM UTC-7, Michael Bayer wrote:
>
>
>
> On 9/18/15 7:58 PM, George Reilly wrote:
>
>
> Thanks for the prompt answer. I tried after_cursor_execute, but it didn't
> really help as I just got a tuple of the values, without a clear way to
> associate them
SQLTap is a very useful library that helps you in profiling SQLAlchemy
queries. It helps you understand where and when SQLAlchemy issues queries,
how often they are issued, how many rows are returned, and if you are
issuing queries with duplicate parameters. The last two are new in
tonight's
I've spent time unsuccessfully trying to fix some problems with a
many-to-many table
and lazy joins.
Here's a simplified repro:
#!/usr/bin/env python
# -*- coding: utf-8 -*-
import random
from sqlalchemy import create_engine, ForeignKey
from sqlalchemy import Column,
Thanks! I went with
Appointment.persons = relationship(
'AppointmentPerson',
cascade='delete-orphan, delete, save-update, merge, expunge',
lazy=LAZYJOIN)
and used the slice notation to empty the InstrumentedList:
appt.persons[:] = []
In my real app, I spent
We ran into a nasty problem with sharding a while back. We came up with an
effective workaround, but we don't fully understand the problem. Perhaps
someone here can provide more insight.
We shard requests to our production MySQL databases using
sqlalchemy.ext.horizontal_shard.ShardedSession.
The combination of create_engine(..., echo=True) and
logging.basicConfig(level=logging.DEBUG)
logging.getLogger('sqlalchemy').setLevel(logging.DEBUG)
does the trick for me now.
Thanks!
/George
--
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To
Is there such a thing as SQLAlchemy training or a SA consultant? I'm
starting to think that my team might benefit from some time with
someone who really knows their stuff.
/George Reilly, Seattle
--
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To
Our production database uses MySQL. For various reasons, the schema
often uses MySQL-specific DDL. We want that represented in our
mapper classes. We also awant to be able to exercise our SQLAlchemy
unit tests against both local MySQL databases and SQLite databases.
Using the MySQL-specific types
Thanks, Michael.
On May 6, 7:48 am, Michael Bayer mike...@zzzcomputing.com wrote:
On May 6, 2010, at 3:35 AM, George V. Reilly wrote:
Our production database uses MySQL. For various reasons, the schema
often uses MySQL-specific DDL. We want that represented in our
mapper classes. We also
a /* comment */ inserted by my code.
/George V. Reilly, Seattle
--
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalch...@googlegroups.com.
To unsubscribe from this group, send email to
sqlalchemy+unsubscr
Michael Bayer wrote:
check out r0ddd638f1d90 in mercurial. I've added the function from the
example below, plus support for in_op(), to the attribute_shard example.
The old ClauseVisitor method is removed and replaced with this more robust
method.
Very nice! Thanks, Michael.
/George
--
On Apr 2, 4:43 pm, George V. Reilly george.v.rei...@gmail.com
wrote:
Michael Bayer wrote:
check out r0ddd638f1d90 in mercurial. I've added the function from the
example below, plus support for in_op(), to the attribute_shard example.
The old ClauseVisitor method is removed and replaced
On Mar 30, 4:42 pm, Michael Bayer mike...@zzzcomputing.com wrote:
George V. Reilly wrote:
We're using SQLAlchemy sharding to partition accounts across a couple
of databases. We want to add more partitions, but first we need to
eliminate some unnecessary cross-partition queries
param)s',
None, type_=UUID())
Typically, I'm seeing this come out of the innards of SQLAlchemy,
as one of several queries triggered by, say, a session.merge().
How do we work around this?
Thanks!
/George V. Reilly, Seattle
--
You received this message because you are subscribed to the Google
16 matches
Mail list logo
