On Thursday, November 8, 2018 at 12:45:57 PM UTC-5, Lele Gaifax wrote:
>
> But maybe I'm missing some detail on the "engine specific"
> implementations,
> where, say, "foo['string']" may be considered a very different operation
> than
> "bar[2]"...
>
Well that also has to do with whatever
It was an error from my hardcoded ddl statement not matching the resulting
Class.__tablename__. So the error was from the database. No issues with
sqlalchemy at all. The resulting Mixin does what I expect.
Thanks again for your incredible dedication on this listserv and with open
source.
-
Jonathan Vanasco writes:
> is the list operation nested?
>
> i.e. the example states:
>
>-
>
>data_table.c.data[('key_1', 'key_2', 5, ..., 'key_n')]
>
>
> does that correspond to:
>
> ['key_1']['key_2']['5']['...']['key_n'] = foo
>
>
> If so, it might make sense to call
is the list operation nested?
i.e. the example states:
-
data_table.c.data[('key_1', 'key_2', 5, ..., 'key_n')]
does that correspond to:
['key_1']['key_2']['5']['...']['key_n'] = foo
If so, it might make sense to call the first two "toplevel index
operations, by key or
the two "index" operations apply to two different datatypes, hash and
list, is it having "key' / "integer" both called "index" operations
that is confusing?
On Thu, Nov 8, 2018 at 11:29 AM Lele Gaifax wrote:
>
> Hi,
>
> in the basic JSON type docstring I see:
>
> The base :class:`.types.JSON`
On Thu, Nov 8, 2018 at 11:23 AM 'Van Klaveren, Brian N.' via
sqlalchemy wrote:
>
> Hi,
>
> Oracle 12.2 now allows 128 character length identifiers:
>
> https://docs.oracle.com/en/database/oracle/oracle-database/12.2/newft/new-features.html#GUID-64283AD6-0939-47B0-856E-5E9255D7246B
>
> It'd be
Hi,
in the basic JSON type docstring I see:
The base :class:`.types.JSON` provides these two operations:
* Keyed index operations::
data_table.c.data['some key']
* Integer index operations::
data_table.c.data[3]
* Path index operations::
Hi,
Oracle 12.2 now allows 128 character length identifiers:
https://docs.oracle.com/en/database/oracle/oracle-database/12.2/newft/new-features.html#GUID-64283AD6-0939-47B0-856E-5E9255D7246B
It'd be great if sqlalchemy knew about this, but what's the proper way of
handling this? Just use the
What operating system platform are you on ?
can you run this for me please?
MariaDB [(none)]> show variables like 'lower_case_table_names';
++---+
| Variable_name | Value |
++---+
| lower_case_table_names | 0 |
easier, if you can give me a "SHOW CREATE TABLE" for a table here that
has foreign key constraints and refers to a column named "id", "ID",
"iD", something with those two letters in it.
On Thu, Nov 8, 2018 at 9:58 AM Mike Bayer wrote:
>
> On Thu, Nov 8, 2018 at 9:56 AM Mike Bayer wrote:
> >
> >
On Thu, Nov 8, 2018 at 9:56 AM Mike Bayer wrote:
>
> On Thu, Nov 8, 2018 at 3:36 AM wrote:
> >
> > Hi
> >
> > I had a problem with alembic autogenerate after updating to version 1.0.2.
> > I'm running MySQL 8.0.11 and Python 3.7.1
> > No matter how my base is defined, I always get the same
On Thu, Nov 8, 2018 at 3:36 AM wrote:
>
> Hi
>
> I had a problem with alembic autogenerate after updating to version 1.0.2.
> I'm running MySQL 8.0.11 and Python 3.7.1
> No matter how my base is defined, I always get the same error. I went through
> the error and found out it comes from
Hi
I had a problem with alembic autogenerate after updating to version 1.0.2.
I'm running MySQL 8.0.11 and Python 3.7.1
No matter how my base is defined, I always get the same error. I went
through the error and found out it comes from function "
_correct_for_mysql_bug_88718(self, fkeys,
13 matches
Mail list logo
