On 01/25/2016 01:41 PM, Lele Gaifax wrote:
> Mike Bayer writes:
>
>> throwing an isinstance() right into the otherwise no-latency __getitem__
>> (the pure python version) there is making me think this may be better as a
>> key fallback, so the expense is limited just to the negative integer cas
On 01/25/2016 02:51 PM, Gastón Avila wrote:
> Hi all,
>
> I have set up specific naming conventions in a Flask-Sqlalchemy app
> using the metadata argument and it all seems to work except for naming
> PRIMARY KEY constraints. Here is what I have
>
> |
> self.db.init_app(app)
> self.db.Model.met
Hi all,
I have set up specific naming conventions in a Flask-Sqlalchemy app using
the metadata argument and it all seems to work except for naming PRIMARY
KEY constraints. Here is what I have
self.db.init_app(app)
self.db.Model.metadata = MetaData(
schema=self.app.config['SQLALCHEMY_DATABASE_S
Mike Bayer writes:
> throwing an isinstance() right into the otherwise no-latency __getitem__
> (the pure python version) there is making me think this may be better as a
> key fallback, so the expense is limited just to the negative integer case
> (or another idea, the negative int keys could be
this is great. but you know throwing an isinstance() right into the
otherwise no-latency __getitem__ (the pure python version) there is
making me think this may be better as a key fallback, so the expense is
limited just to the negative integer case (or another idea, the negative
int keys could be
Here is a rectified diff, handling fixing the Py2 case:
diff --git a/lib/sqlalchemy/cextension/resultproxy.c
b/lib/sqlalchemy/cextension/resultproxy.c
index 9c4d0c7..331fae2 100644
--- a/lib/sqlalchemy/cextension/resultproxy.c
+++ b/lib/sqlalchemy/cextension/resultproxy.c
@@ -
Here is my initial diff:
diff --git a/lib/sqlalchemy/cextension/resultproxy.c
b/lib/sqlalchemy/cextension/resultproxy.c
index 9c4d0c7..3e40ec1 100644
--- a/lib/sqlalchemy/cextension/resultproxy.c
+++ b/lib/sqlalchemy/cextension/resultproxy.c
@@ -271,6 +271,8 @@ BaseRowProxy_su
