#1944: enhance mysql update to take updates from other tables
---------------------------------------+------------------------------------
Reporter: guest | Type: enhancement
Status: new | Priority: medium
Milestone: 0.6.xx | Component: mysql
Severity: no triage selected yet | Keywords: update
Status_field: needs tests |
---------------------------------------+------------------------------------
Comment(by guest):
here is a patch for the changes I've made (patch -p1 < update.patch). I've
run
the complete suite of tests for mysql,postgresql plus the jython
equivalents with zxjdbc
and all looks OK. My changes for mssql look OK too but I've only run part
of the test suite for 'mssql+pyodbc'.
For the life of me I can't get nose to complete for mssql. Either it hangs
on some tests (e.g.
test.orm.tests_session.SessionTest.test_autoflush) or it chokes on a
Unicode or binary test (under FreeTDS,unixODBC).
I've tried variations of pyodbc on Vista and with FreeTDS on Ubuntu plus
jython and zxjdbc but no luck.
I all seems to work *almost* but not quite.
Would the fact that I'm running these tests through a ssh tunnel be the
problem?
Is there a magic connection string keyword I'm missing?
Also I think I could extend the Update syntax to Oracle also but I don't
have access to a server I can do the
tests on.
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/1944#comment:6&gt;
sqlalchemy <http://www.sqlalchemy.org/&gt;
The Database Toolkit for Python

#1959: Upgrade from MySQL 5.1.41 to 5.1.49 breaks simple SQLAlchemy queries.
-----------------------------------------+----------------------------------
Reporter: guest | Type: defect
Status: new | Priority: medium
Milestone: | Component: mysql
Severity: no triage selected yet | Keywords:
Status_field: needs questions answered |
-----------------------------------------+----------------------------------
Comment(by zzzeek):
Replying to [comment:3 guest]:
> I would also like to add that, in my experience, the database engine is
generally never the cause of a problem. It real cause might be some
misconfiguration or an application error, but in this case I have not been
able to detect any such errors.
They are rare but I have seen database engine bugs with both SQLite and
MySQL. MySQL more often, though not as rudimentary as this one.
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/1959#comment:4&gt;
sqlalchemy <http://www.sqlalchemy.org/&gt;
The Database Toolkit for Python

#1959: Upgrade from MySQL 5.1.41 to 5.1.49 breaks simple SQLAlchemy queries.
-----------------------------------------+----------------------------------
Reporter: guest | Type: defect
Status: new | Priority: medium
Milestone: | Component: mysql
Severity: no triage selected yet | Keywords:
Status_field: needs questions answered |
-----------------------------------------+----------------------------------
Comment(by guest):
Replying to [comment:2 zzzeek]:
> things to look at:
>
> 1. current version of MySQL is 5.1.51. Have you tried that ?
I am sorry, but I have not tried that (yet). I have only had time to try
the Ubuntu
packages so far.
> 2. Have you reproduced the issue with a raw SQL script ? That's the
very first thing you do with a behavioral difference so obvious. You
then report a bug to MySQL if confirmed.
>
> 3. I don't see the INSERT statements in your logs. Have you confirmed
that the issue is not on the INSERT side ? (this would fall under #2)
I have now stripped away the superflous information from the logs, and
ended up with a pure SQL script, which I have attached. I tried to tell
you that I had tried the same in pure SQL, and that the results were the
same.
I will see if I can reproduce this under MySQL 5.1.51 too, and if the
behavior is still different, I was actually planning on reporting those
results to MySQL.
> 4. Have you verified the MySQL installation doesn't have an issue ?
At least, I have not been able to observe any issues. I have now tried
with a completely clean MySQL server install, where the old database files
were moved away. And the server log seems OK enough:
101027 20:30:13 [Note] /usr/sbin/mysqld: Normal shutdown
101027 20:30:13 [Note] Event Scheduler: Purging the queue. 0 events
101027 20:30:15 InnoDB: Starting shutdown...
101027 20:30:19 InnoDB: Shutdown completed; log sequence number 0 68152
101027 20:30:19 [Note] /usr/sbin/mysqld: Shutdown complete
101027 20:30:43 [Note] Plugin 'FEDERATED' is disabled.
101027 20:30:43 InnoDB: Started; log sequence number 0 68152
101027 20:30:43 [Note] Event Scheduler: Loaded 0 events
101027 20:30:43 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.1.49-1ubuntu8' socket: '/var/run/mysqld/mysqld.sock' port:
3306 (Ubuntu)
But, the strange behavior still occurs. I guess I have to move on to the
5.1.51 release then.
> 5. Did you try the latest MySQLdb DBAPI ? Alternate DBAPIs like OurSQL
?
I used MySQLdb version 1.2.3c1 and got the same behavior with OurSQL
version 0.9.2. As I mentioned initially in my report, I observe this
strange behavior independent of SQLAlchemy (that is, with "pure SQL") too,
so I do not actually call this a bug in SQLAlchemy.
> The query itself is extremely simple so I don't see what could be done
here if 5.1.49 is so severely broken, though I didn't notice anything in
their changelog subsequent, which suggests this might be something more
subtle.
I absolutely agree. It may definitely be something wrong somewhere in my
configuration, but (as far as I know) I have only used Ubuntu defaults.
I would also like to add that, in my experience, the database engine is
generally never the cause of a problem. It real cause might be some
misconfiguration or an application error, but in this case I have not been
able to detect any such errors.
Thank you for your help so far.
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/1959#comment:3&gt;
sqlalchemy <http://www.sqlalchemy.org/&gt;
The Database Toolkit for Python

#1959: Upgrade from MySQL 5.1.41 to 5.1.49 breaks simple SQLAlchemy queries.
-----------------------------------------+----------------------------------
Reporter: guest | Type: defect
Status: new | Priority: medium
Milestone: | Component: mysql
Severity: no triage selected yet | Keywords:
Status_field: needs questions answered |
-----------------------------------------+----------------------------------
Changes (by zzzeek):
* status_field: awaiting triage => needs questions answered
Comment:
things to look at:
1. current version of MySQL is 5.1.51. Have you tried that ?
2. Have you reproduced the issue with a raw SQL script ? That's the very
first thing you do with a behavioral difference so obvious. You then
report a bug to MySQL if confirmed.
3. I don't see the INSERT statements in your logs. Have you confirmed
that the issue is not on the INSERT side ? (this would fall under #2)
4. Have you verified the MySQL installation doesn't have an issue ?
5. Did you try the latest MySQLdb DBAPI ? Alternate DBAPIs like OurSQL ?
The query itself is extremely simple so I don't see what could be done
here if 5.1.49 is so severely broken, though I didn't notice anything in
their changelog subsequent, which suggests this might be something more
subtle.
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/1959#comment:2&gt;
sqlalchemy <http://www.sqlalchemy.org/&gt;
The Database Toolkit for Python

#1959: Upgrade from MySQL 5.1.41 to 5.1.49 breaks simple SQLAlchemy queries.
---------------------------------------+------------------------------------
Reporter: guest | Type: defect
Status: new | Priority: medium
Milestone: | Component: mysql
Severity: no triage selected yet | Keywords:
Status_field: awaiting triage |
---------------------------------------+------------------------------------
First of all, thank you for a wonderful ORM. It is mostly a joy
developing with it.
When I upgraded from Ubuntu Lucid Lynx, 10.04, to Maverick Meerkat, 10.10,
the other day, which included an upgrade of MySQL from 5.1.41 to 5.1.49,
many of my simple SQLAlchemy (SA) queries began to falsely return empty
sets.
When running with a MySQL 5.1.41 database, the attached script correctly
returns the output shown in the attached output files, *5.1.41.txt.
However, as shown in the other attached output files, *5.1.49.txt, the
same queries then return empty sets.
This also breaks when typed directly into the MySQL command line tool.
Therefore, this can probably not be blamed on SA, but perhaps the query
generator in SA should be updated?
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/1959&gt;
sqlalchemy <http://www.sqlalchemy.org/&gt;
The Database Toolkit for Python

#1957: Full outer join support as a sql expression
-----------------------------+----------------------------------------------
Reporter: guest | Owner: zzzeek
Type: enhancement | Status: new
Priority: medium | Milestone: 0.6.xx
Component: sql | Severity: no triage selected yet
Keywords: full outer join | Status_field: awaiting triage
-----------------------------+----------------------------------------------
For comparing the contents of two relatively small tables with relatively
few columns I find full outer join much more reasonable to read than the
equivalent long coalesce statements. It would be a nice addition to the
already extensive set of capabilities, IMHO.
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/1957&gt;
sqlalchemy <http://www.sqlalchemy.org/&gt;
The Database Toolkit for Python