Thanks for the response -- this is really useful information about what 
MySQL features new to version 5.5 are not handled by MySQLdb. 

In this case, my reasons for asking about using MySQL 5.5 aren't really 
about wanting any features that are available only in 5.5, but more about a 
situation where the choice of MySQL version isn't entirely up to me.  I'm 
hoping to avoid spending time configuring a development environment with 
this version only to find out that this actually doesn't work at all.  So 
from your response I get that probably it would work. 

Is there anyone out there who's actually tried it and knows from experience 
what will happen?  If not, I'll try it and update this thread with how it 
comes out. 



On Sunday, September 30, 2012 1:38:45 PM UTC-4, Dennis Lee Bieber wrote:
>
> On Sun, 30 Sep 2012 09:18:49 -0700 (PDT), Elizabeth Rachel Lemon 
> <ele...@gmail.com <javascript:>> declaimed the following in 
> gmane.comp.python.django.user: 
>
> > Is anyone using Django with MySQL 5.5? The page that says "5.0.3 and 
> > higher" seems to me to imply that this would work, but if MySQLdb is 
> > required for Django and MySQLdb only supports up to 5.1, then that 
> implies 
> > that it is at least not supported. Anyone tried it? 
>
>         The main features that have been added to MySQL are views, 
> triggers, 
> stored procedures... And "prepared statements". 
>
>         So far as I know, the only thing MySQLdb doesn't handle is the 
> "prepared statements" aspect -- it uses the query interface that is 
> common to all versions: it sends complete text queries. The main place 
> where the difference would be visible is if one does an .executemany(). 
>
>         The common-to-all versions would issue multiple complete 
> statements, 
> which need to be parsed and compiled by MySQL /each time/: 
>
> insert into thetable (f1, f2, f3) values (v11, v12, v13) 
> insert into thetable (f1, f2, f3) values (v21, v22, v23) 
> insert into thetable (f1, f2, f3) values (v31, v32, v33) 
>
>         Prepared statements would send a parameterized statement to MySQL 
> to 
> be "compiled" 
>
> insert into thetable (f1, f2, f3) values (?1, ?2, ?3) 
>
> and then send the values separately, telling MySQL to use the already 
> compiled statement 
>
> stmtref, v11, v12, v13 
> stmtref, v21, v22, v23 
> stmtref, v31, v32, v33 
>
>         I'd find it highly unlikely that MySQL would have /removed/ some 
> portion of the API that would invalidate pre-existing application code. 
>
> -- 
>         Wulfraed                 Dennis Lee Bieber         AF6VN 
>         wlf...@ix.netcom.com <javascript:>    
> HTTP://wlfraed.home.netcom.com/ 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/qmkYEYLqjc4J.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Reply via email to