On Wed, Dec 7, 2011 at 11:40 PM, Vinay Sajip wrote:
>
> On Dec 8, 6:46 am, Ian Clelland wrote:
> >
> > There also seem to be a number of unicode-related errors there (mixed
> > collations; unrecognized characters) -- Could that be related to the
> lines
>
> I'm also getting the same errors on 2.x
On Dec 8, 6:46 am, Ian Clelland wrote:
>
> There also seem to be a number of unicode-related errors there (mixed
> collations; unrecognized characters) -- Could that be related to the lines
I'm also getting the same errors on 2.x with the 2.x adapter on
unpatched Django - so it might well be to
On Dec 8, 6:46 am, Ian Clelland wrote:
>
> use_unicode used to be unconditional on the database connection; now you've
> removed it, but just for Python 3.
>
I looked into it a little further - the use_unicode flag is just used
in the 2.x constructor to set default converters to return unicode
i
On Dec 8, 6:46 am, Ian Clelland wrote:
> There also seem to be a number of unicode-related errors there (mixed
> collations; unrecognized characters) -- Could that be related to the lines
> in your patched mysql/base.py:
>
> if not PY3:
> kwargs['use_unicode'] = True
On Wed, Dec 7, 2011 at 9:59 PM, Vinay Sajip wrote:
> On Dec 7, 8:38 pm, Ian Clelland wrote:
>
> > Thoughts?
>
> A further update: of my 24 failures, 17 are in multiple_database, as
> are 3 failures. But I get the same errors with unpatched Django 2.x
> running with the standard 2.x MySQLdb adapt
On Dec 7, 8:38 pm, Ian Clelland wrote:
> Thoughts?
A further update: of my 24 failures, 17 are in multiple_database, as
are 3 failures. But I get the same errors with unpatched Django 2.x
running with the standard 2.x MySQLdb adapter, so it might be
something to do with my MySQL configuration.
On Dec 7, 8:38 pm, Ian Clelland wrote:
> Thoughts?
The Django test run using MySQLdb at
https://github.com/vsajip/MySQL-for-Python-3
completed with 24 failures, 9 errors, so your PyMySQL results are
better at 5 failures, 2 errors. I will dig in a little further into
these issues. Details at h
Re Russell: Pertaining to autocommit, I wrapped the view (my base
view's dispatch method) in commit_on_success. I asked here (as opposed
to opening a ticket) because I wasn't certain there was a way to fix
this, but it just seemed too wrong to not at least bring to the table.
After Karen's reply I'
This is exactly what I've been struggling with today! Specifically the
ordering of a related object. More specifically the UserProfile created
for User. Currently I seemingly have no control in integrating with the
admin form and am stuck with my User extension as a stacked inline appended
t
On Wed, Dec 7, 2011 at 6:21 PM, Russell Keith-Magee wrote:
> I don't consider it a bug
> that Django exposes a database error in this case.
>
I didn't hear what sounded like a database error in this case. The original
note says:
Upon attempting to save, you'll receive an error message stating,
Just finished a full suite test, with the PyMySQL adapter, and I'm down to
5 failures and 2 errors:
Gory details:
http://dpaste.com/hold/667992/
--
Regards,
Ian Clelland
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this gr
On Wed, Dec 7, 2011 at 10:59 AM, Yo-Yo Ma wrote:
> Take the following models:
>
> class Person(models.Model):
> name = models.CharField(_('Person'), max_length=255)
>
> class Production(models.Model):
> person = models.ForeignKey(Person)
> title = models.CharField(_('Title'), max_length=2
On Wed, Dec 7, 2011 at 5:17 PM, Ian Clelland wrote:
> On Wed, Dec 7, 2011 at 1:07 PM, Alex Gaynor wrote:
>
>> I'm saying database backends need badly to me refactored to split up
>> these two seperate concerns.
>>
>
> Agreed, then. Is there a ticket for this already? (I don't see anything in
> t
On Wed, Dec 7, 2011 at 1:07 PM, Alex Gaynor wrote:
> I'm saying database backends need badly to me refactored to split up these
> two seperate concerns.
>
Agreed, then. Is there a ticket for this already? (I don't see anything in
the DB component, looking for 'backend' anywhere in the
summary/ke
On Dec 7, 8:38 pm, Ian Clelland wrote:
>
> 3. Code speaks, I know -- what's the best way to share this? I've sent
> Vinay a patch, but that's for his Py3k branch, and might not get the
> audience that something like this needs. I'm doing it for Py3k support, but
> ideally it would work just as wel
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/07/2011 07:25 AM, Thibault Jouannic wrote:
> https://github.com/django/django/pull/87
>
> Hope I did everything right.
>
> I've read the submitting patches doc, but is a git pull request
> accepted? Otherwise, Should I upload a patch in the clo
On Wed, Dec 7, 2011 at 12:56 PM, Jannis Leidel wrote:
>
> Ian,
>
> > This is a proposal to add support in Django for PyMySQL[1] as an
> optional replacement for MySQLdb.
> >
> > I've been working with Vinay Sajip's Python 3-compatible branch; trying
> to get MySQL support working, and I have had
On Wed, Dec 7, 2011 at 4:03 PM, Ian Clelland wrote:
>
>
> On Wed, Dec 7, 2011 at 12:48 PM, Alex Gaynor wrote:
>
>> It's a fine goal, though I'm not convinced this should necessarily ship
>> with Django given PyMySQL has relatively few users.
>
>
> Agreed; I just don't know of another way to suppo
On Wed, Dec 7, 2011 at 12:48 PM, Alex Gaynor wrote:
> It's a fine goal, though I'm not convinced this should necessarily ship
> with Django given PyMySQL has relatively few users.
Agreed; I just don't know of another way to support Python 3 and MySQL,
without pushing the MySQLdb developers to a
Ian,
> This is a proposal to add support in Django for PyMySQL[1] as an optional
> replacement for MySQLdb.
>
> I've been working with Vinay Sajip's Python 3-compatible branch; trying to
> get MySQL support working, and I have had a great deal of success, using
> PyMySQL as a back end, rather
On 3 déc. 2011, at 23:36, Jonas H. wrote:
> On Jacob's suggestion in this thread [1] back in April, I split the diff
> between Django trunk and Django-nonrel into logically separated patches.
>
> I uploaded most of them to the ticket tracker (a few things are still missing
> but these are the mo
On Wed, Dec 7, 2011 at 3:38 PM, Ian Clelland wrote:
> Hi, all ---
>
> This is a proposal to add support in Django for PyMySQL[1] as an optional
> replacement for MySQLdb.
>
> I've been working with Vinay Sajip's Python 3-compatible branch; trying to
> get MySQL support working, and I have had a g
Hi, all ---
This is a proposal to add support in Django for PyMySQL[1] as an optional
replacement for MySQLdb.
I've been working with Vinay Sajip's Python 3-compatible branch; trying to
get MySQL support working, and I have had a great deal of success, using
PyMySQL as a back end, rather than MyS
After reading all the comments, I now completely agree that Django is doing
the right thing and it falls onto the user to do sanity checking.
Always helps to have another set of eyes, so thank you to everyone who took
time to post their thoughts!
Cal
On Tue, Dec 6, 2011 at 7:54 AM, Paul McMillan
Fwiw, for the last number of months we've been telling people that pull
requests are fine in lieu of uploaded patch, but the pull request still needs
to be linked from a Trac ticket (so Trac remains the single source of truth).
Carl
--
Sent from my Android phone with K-9 Mail. Please excuse my
On Wed, Dec 7, 2011 at 8:25 AM, Thibault Jouannic wrote:
> I've read the submitting patches doc, but is a git pull request
> accepted?
For now, no. We'll be moving to GitHub in the near future, but
currently we're using Subversion/Trac. Upload a patch via the ticket
tracker (code.djangoproject.co
On Wed, Dec 7, 2011 at 7:55 AM, Vinay Sajip wrote:
>
> On Dec 7, 3:50 pm, Ian Clelland wrote:
> > I'm using PyMySQL (https://github.com/petehunt/PyMySQL) -- it's almost a
> > drop-in replacement for MySQLdb. The biggest change is in the data
> > converters -- they have a different function signa
On Dec 7, 3:50 pm, Ian Clelland wrote:
> I'm using PyMySQL (https://github.com/petehunt/PyMySQL) -- it's almost a
> drop-in replacement for MySQLdb. The biggest change is in the data
> converters -- they have a different function signature from MySQLdb's.
>
> I have had to make a couple of patche
On Wed, Dec 7, 2011 at 4:14 AM, Vinay Sajip wrote:
> On Dec 7, 5:53 am, Ian Clelland wrote:
> > On Tuesday, December 6, 2011, Ian Kelly wrote:
> > > itertools.izip_longest was added in Python 2.6, though, so a
> > > compatibility function is needed for Python 2.5.
> >
> > Ahh, that's a good cat
Hi again,
> Please add a patch to the tracker, since it always best if people with the
> problem write it as they know what's missing.
Done.
https://github.com/django/django/pull/87
Hope I did everything right.
I've read the submitting patches doc, but is a git pull request
accepted? Otherwise
Hi,
On Wednesday, December 7, 2011 11:09:38 AM UTC+1, Thibault Jouannic wrote:
>
> If I'm not wrong, only the PUT method can specify POST like
> parameters.
>
Before writing my answer I did look on w3c and at least OPTIONS is allowed
to have a body (can't tell you if it has to be a specific cont
On Dec 7, 5:53 am, Ian Clelland wrote:
> On Tuesday, December 6, 2011, Ian Kelly wrote:
> > itertools.izip_longest was added in Python 2.6, though, so a
> > compatibility function is needed for Python 2.5.
>
> Ahh, that's a good catch. I'll have to make use of your solution, then.
>
I've already
On Dec 7, 5:14 am, "Joe & Anne Tennies" wrote:
> So, I hg pull; hg update and reran the Python3 tests. The Egg import test
> passes now.
>
> The attached patch fix makes the last 2 tests pass in both 2.7.2 and 3.2.1
> under postgres and sqlite. I'll be honest and say I don't know why, so
> please
Hi,
> That would be really odd imo and confusing as hell if you find
> PUT/DELETE/HEAD/OPTIONS/whatever data in request.POST
If I'm not wrong, only the PUT method can specify POST like
parameters.
> put_data = QueryDict(self.raw_post_data, encoding=your_encoding)
> not really hard if you ask me.
Hi,
On Wednesday, December 7, 2011 9:33:52 AM UTC+1, Thibault Jouannic wrote:
> So, don't you think the `request.POST` variable should be processed
> for every request with the "x-www-form-urlencoded" content type,
> whatever the http verb is?
>
That would be really odd imo and confusing as hell
Actually, I've been thinking about this issue, read again the bug
report and current thread, and I'd like to re-open the discussion, if
you don't mind.
> request.POST is a
> special-case for a request body submitted with the
> "x-www-form-urlencoded" or "multipart/form-data" content types. This is
36 matches
Mail list logo
