Re: Potential bug: mysql-connector-python Django 3.2.11 and third-party packages that populate the Admin Site

[Richard Mayebo]

mysql-connector-python 8.0.27 has another bug (see
https://stackoverflow.com/questions/69900463/django-migration-error-typeerror-sequence-item-1-expected-a-bytes-like-object
)
so I did not try it.

mysql-connector-python 8.0.26 did not have this problem with Django 3.1. So
the bug must have been introduced in the transition to Django 3.2.

>From what I am picking up (for example from Lakshyaraj Dash above),
mysql-connector-python seems to be buggy generally and mysqlclient should
be used as the first choice.

On Thu, Feb 3, 2022 at 4:14 PM Jason  wrote:

> can you observe the same behavior in previous versions of connector?  You
> listed two patch versions, makes me curious where in the 8.x version line
> this works.  Likely this is an issue with mysql-connector-python, but with
> it being an Oracle product, it doesn't have much internal visibility.  So
> could be helpful to downgrade versions till you get a working one.
>
> On Wednesday, February 2, 2022 at 9:01:51 PM UTC-5 dashlaksh...@gmail.com
> wrote:
>
>> Use only the mysqlclient package to populate your admin site with MySQL
>> database.
>>
>> You can watch this tutorial also : https://youtu.be/SNyCV8vOr-g
>>
>> On Thu, Feb 3, 2022, 06:19 Richard Mayebo  wrote:
>>
>>> Platform: Observed on Ubuntu 20.04
>>>
>>>
>>>1. Install MySQL (Observed on 5.7 and 8.0)
>>>2. Create a Virtual environment using venv, and activate it.
>>>3. Install Django 3.2.11
>>>4. Install mysql-connector-python (Observed on 8.0.26 and 8.0.28)
>>>5. Install django-easy-audit and/or django-axes (both these third
>>>party packages populate the Django Admin Site, where the apparent bug
>>>manifests).
>>>6. Create a superuser (python manage.py createsuperuser)
>>>7. Start Django (python manage.py runserver)
>>>8. Launch the Django Admin Site and log in with the superuser.
>>>9. The pane on the left hand side will have links to objects created
>>>by django-easy-audit and/or django-axes, depending on what was installed.
>>>10. Click on the "Request event" link under "Easy Audit Application"
>>>or "Access logs" under "Axes"
>>>11. RESULT:
>>>
>>> Template error: In template
>>> /home//.venv/lib/python3.8/site-packages/django/contrib/admin/templates/admin/base.html,
>>> error at line 44
>>>
>>>'NoneType' object has no attribute 'day' [*OR  'NoneType' object has
>>> no attribute 'month'*]
>>>
>>> This behaviour is observed on MySQL 5.7.37 and 8.0.26 using
>>> my-sql-connector 8.0.26 and 8.0.28.
>>>
>>> Replacing MySQL with SQLite or PostgreSQL 12 solves the issue.
>>>
>>> Replacing the connector with mysqlclient-2.1.0 solves the issue.
>>>
>>> This implies there is a bug in the interaction between third-party
>>> packages like django-easy-audit and django-axes, Django 3.2.11 and
>>> my-sql-connector 8.0.26 and 8.0.28.
>>>
>>> Has similar behaviour been observed by anyone else? In any case, how can
>>> this be brought to the attention of the development team?
>>>
>>> My apologies if this is the wrong forum for this post. I am new at this.
>>> Regards,
>>> Richard.
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Django users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to django-users...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/django-users/0a483673-3393-42f9-87a1-c4463c583d7dn%40googlegroups.com
>>> 
>>> .
>>>
>> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-users/s1s42RcxNMQ/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> django-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/d3eda24e-ab25-406c-9992-3af6f98701c1n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAHYamgAJvB8M9b3c_Mqd8t7ZbbWMnYjjCHhF-Cvme9V%3D18E3fA%40mail.gmail.com.

Re: Potential bug: mysql-connector-python Django 3.2.11 and third-party packages that populate the Admin Site

[Jason]

can you observe the same behavior in previous versions of connector?  You 
listed two patch versions, makes me curious where in the 8.x version line 
this works.  Likely this is an issue with mysql-connector-python, but with 
it being an Oracle product, it doesn't have much internal visibility.  So 
could be helpful to downgrade versions till you get a working one.

On Wednesday, February 2, 2022 at 9:01:51 PM UTC-5 dashlaksh...@gmail.com 
wrote:

> Use only the mysqlclient package to populate your admin site with MySQL 
> database.
>
> You can watch this tutorial also : https://youtu.be/SNyCV8vOr-g
>
> On Thu, Feb 3, 2022, 06:19 Richard Mayebo  wrote:
>
>> Platform: Observed on Ubuntu 20.04
>>
>>
>>1. Install MySQL (Observed on 5.7 and 8.0)
>>2. Create a Virtual environment using venv, and activate it.
>>3. Install Django 3.2.11
>>4. Install mysql-connector-python (Observed on 8.0.26 and 8.0.28)
>>5. Install django-easy-audit and/or django-axes (both these third 
>>party packages populate the Django Admin Site, where the apparent bug 
>>manifests).
>>6. Create a superuser (python manage.py createsuperuser)
>>7. Start Django (python manage.py runserver)
>>8. Launch the Django Admin Site and log in with the superuser.
>>9. The pane on the left hand side will have links to objects created 
>>by django-easy-audit and/or django-axes, depending on what was installed.
>>10. Click on the "Request event" link under "Easy Audit Application" 
>>or "Access logs" under "Axes"
>>11. RESULT: 
>>
>> Template error: In template 
>> /home//.venv/lib/python3.8/site-packages/django/contrib/admin/templates/admin/base.html,
>>  
>> error at line 44
>>
>>'NoneType' object has no attribute 'day' [*OR  'NoneType' object has 
>> no attribute 'month'*] 
>>
>> This behaviour is observed on MySQL 5.7.37 and 8.0.26 using 
>> my-sql-connector 8.0.26 and 8.0.28.
>>
>> Replacing MySQL with SQLite or PostgreSQL 12 solves the issue. 
>>
>> Replacing the connector with mysqlclient-2.1.0 solves the issue. 
>>
>> This implies there is a bug in the interaction between third-party 
>> packages like django-easy-audit and django-axes, Django 3.2.11 and 
>> my-sql-connector 8.0.26 and 8.0.28.
>>
>> Has similar behaviour been observed by anyone else? In any case, how can 
>> this be brought to the attention of the development team?
>>
>> My apologies if this is the wrong forum for this post. I am new at this.
>> Regards,
>> Richard.
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-users...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-users/0a483673-3393-42f9-87a1-c4463c583d7dn%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/d3eda24e-ab25-406c-9992-3af6f98701c1n%40googlegroups.com.

Re: Potential bug: mysql-connector-python Django 3.2.11 and third-party packages that populate the Admin Site

[Lakshyaraj Dash X-D 25]

Use only the mysqlclient package to populate your admin site with MySQL
database.

You can watch this tutorial also : https://youtu.be/SNyCV8vOr-g

On Thu, Feb 3, 2022, 06:19 Richard Mayebo  wrote:

> Platform: Observed on Ubuntu 20.04
>
>
>1. Install MySQL (Observed on 5.7 and 8.0)
>2. Create a Virtual environment using venv, and activate it.
>3. Install Django 3.2.11
>4. Install mysql-connector-python (Observed on 8.0.26 and 8.0.28)
>5. Install django-easy-audit and/or django-axes (both these third
>party packages populate the Django Admin Site, where the apparent bug
>manifests).
>6. Create a superuser (python manage.py createsuperuser)
>7. Start Django (python manage.py runserver)
>8. Launch the Django Admin Site and log in with the superuser.
>9. The pane on the left hand side will have links to objects created
>by django-easy-audit and/or django-axes, depending on what was installed.
>10. Click on the "Request event" link under "Easy Audit Application"
>or "Access logs" under "Axes"
>11. RESULT:
>
> Template error: In template
> /home//.venv/lib/python3.8/site-packages/django/contrib/admin/templates/admin/base.html,
> error at line 44
>
>'NoneType' object has no attribute 'day' [*OR  'NoneType' object has
> no attribute 'month'*]
>
> This behaviour is observed on MySQL 5.7.37 and 8.0.26 using
> my-sql-connector 8.0.26 and 8.0.28.
>
> Replacing MySQL with SQLite or PostgreSQL 12 solves the issue.
>
> Replacing the connector with mysqlclient-2.1.0 solves the issue.
>
> This implies there is a bug in the interaction between third-party
> packages like django-easy-audit and django-axes, Django 3.2.11 and
> my-sql-connector 8.0.26 and 8.0.28.
>
> Has similar behaviour been observed by anyone else? In any case, how can
> this be brought to the attention of the development team?
>
> My apologies if this is the wrong forum for this post. I am new at this.
> Regards,
> Richard.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/0a483673-3393-42f9-87a1-c4463c583d7dn%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAF7qQgCXChSXEoZsFHLK1gcCVh7pPdhiAqrOdmxOXdVdtYPinw%40mail.gmail.com.

Potential bug: mysql-connector-python Django 3.2.11 and third-party packages that populate the Admin Site

[Richard Mayebo]

Platform: Observed on Ubuntu 20.04


   1. Install MySQL (Observed on 5.7 and 8.0)
   2. Create a Virtual environment using venv, and activate it.
   3. Install Django 3.2.11
   4. Install mysql-connector-python (Observed on 8.0.26 and 8.0.28)
   5. Install django-easy-audit and/or django-axes (both these third party 
   packages populate the Django Admin Site, where the apparent bug manifests).
   6. Create a superuser (python manage.py createsuperuser)
   7. Start Django (python manage.py runserver)
   8. Launch the Django Admin Site and log in with the superuser.
   9. The pane on the left hand side will have links to objects created by 
   django-easy-audit and/or django-axes, depending on what was installed.
   10. Click on the "Request event" link under "Easy Audit Application" or 
   "Access logs" under "Axes"
   11. RESULT: 

Template error: In template 
/home//.venv/lib/python3.8/site-packages/django/contrib/admin/templates/admin/base.html,
 
error at line 44

   'NoneType' object has no attribute 'day' [*OR  'NoneType' object has no 
attribute 'month'*] 

This behaviour is observed on MySQL 5.7.37 and 8.0.26 using 
my-sql-connector 8.0.26 and 8.0.28.

Replacing MySQL with SQLite or PostgreSQL 12 solves the issue. 

Replacing the connector with mysqlclient-2.1.0 solves the issue. 

This implies there is a bug in the interaction between third-party packages 
like django-easy-audit and django-axes, Django 3.2.11 and my-sql-connector 
8.0.26 and 8.0.28.

Has similar behaviour been observed by anyone else? In any case, how can 
this be brought to the attention of the development team?

My apologies if this is the wrong forum for this post. I am new at this.
Regards,
Richard.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/0a483673-3393-42f9-87a1-c4463c583d7dn%40googlegroups.com.

Re: Potential Bug in django.contrib.gis

[Janis]

Additional Info: I get this behavious in python 3.6.7, which according to 
the documentation should be compatible with django 3.1.

Janis schrieb am Donnerstag, 3. September 2020 um 17:16:50 UTC+2:

>
> Hi all,
> I recently upgraded django 1.11 to 3.1. Now, in dango 3.1, the following 
> example code from 
> https://docs.djangoproject.com/en/3.1/ref/contrib/gis/geos/#django.contrib.gis.geos.Polygon
> produces a Segfault. 
>
> Code snippet:
> >>> from django.contrib.gis.geos import Point, LineString, Polygon, 
> LinearRing
> >>> ext_coords = ((0, 0), (0, 1), (1, 1), (1, 0), (0, 0))
> >>> int_coords = ((0.4, 0.4), (0.4, 0.6), (0.6, 0.6), (0.6, 0.4), (0.4, 
> 0.4))
> >>> poly = Polygon(ext_coords, int_coords)
> >>> [c for c in poly]
> [,  0x7f4796e4f2b8>]
> >>> [c for c in poly[0]]
> Segmentation fault (core dumped)
>
> I can also provoke this error with next():
> >>> from django.contrib.gis.geos import Point, LineString, Polygon, 
> LinearRing
> >>> ext_coords = ((0, 0), (0, 1), (1, 1), (1, 0), (0, 0))
> >>> int_coords = ((0.4, 0.4), (0.4, 0.6), (0.6, 0.6), (0.6, 0.4), (0.4, 
> 0.4))
> >>> poly = Polygon(ext_coords, int_coords)
> >>> next(poly[0].__iter__())
> Segmentation fault (core dumped)
>
> Is this a bug or might there be another reason (e.g. hardware-related 
> issue)?
>
> Thanks, 
> Janis
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/3f739f4a-84ce-4ed2-a615-70dc5096e498n%40googlegroups.com.

Potential Bug in django.contrib.gis

[Janis Goldzycher]

Hi all,
I recently upgraded django 1.11 to 3.1. Now, in dango 3.1, the following 
example code from 
https://docs.djangoproject.com/en/3.1/ref/contrib/gis/geos/#django.contrib.gis.geos.Polygon
produces a Segfault. 

Code snippet:
>>> from django.contrib.gis.geos import Point, LineString, Polygon, 
LinearRing
>>> ext_coords = ((0, 0), (0, 1), (1, 1), (1, 0), (0, 0))
>>> int_coords = ((0.4, 0.4), (0.4, 0.6), (0.6, 0.6), (0.6, 0.4), (0.4, 
0.4))
>>> poly = Polygon(ext_coords, int_coords)
>>> [c for c in poly]
[, ]
>>> [c for c in poly[0]]
Segmentation fault (core dumped)

I can also provoke this error with next():
>>> from django.contrib.gis.geos import Point, LineString, Polygon, 
LinearRing
>>> ext_coords = ((0, 0), (0, 1), (1, 1), (1, 0), (0, 0))
>>> int_coords = ((0.4, 0.4), (0.4, 0.6), (0.6, 0.6), (0.6, 0.4), (0.4, 
0.4))
>>> poly = Polygon(ext_coords, int_coords)
>>> next(poly[0].__iter__())
Segmentation fault (core dumped)

Is this a bug or might there be another reason (e.g. hardware-related 
issue)?

Thanks, 
Janis

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/f204bcbb-fd18-44af-83de-917377b9d465n%40googlegroups.com.

Re: potential bug

[Mark Nesterovych]

Forgot about ModelChoise.
Thank you.

On Sunday, 14 June 2015 22:37:26 UTC+3, Tom Evans wrote:
>
> On Sun, Jun 14, 2015 at 3:24 PM, Mark Nesterovych 
>  wrote: 
> > Hello. 
> > I've just finished small django site, and keep going on creating tests. 
> > I've found and issue with Model.objects.values_list  method. 
> > Looks like it disregard test database and looks into production one. 
> > 
> > Some details. 
> > I have a form with a filed customer = 
> > forms.ChoiseField(choises=Customer.objects.values_list('id', 'name')) 
> > 
> > When this form initing during tests, it loads data from production 
> database. 
> > 
> > My test looks like this. 
> > class CustomerFormTest(TestCase): 
> > def setUp: 
> >  self.customer = Customer.objects.create(name='test name') 
> > 
> > def test_form_creation(self): 
> > form = CustomerLoginForm() 
> > self.assertIn('test name', form.as_ul()) 
> > 
> > 
> > Assertion fails, and when I printing form content, I see select widget 
> with 
> > options from production database objects. 
> > 
> > Can somebody confirm it's a bug ? 
> > Thank you. 
>
> It's not a bug. You are specifying the choices when the form is 
> defined, and at that point there is nothing in the database and so the 
> form has no choices. Since the field is never redefined in the form, 
> the choices will be whatever existed in the database when the form is 
> defined, which is a bad way of designing the form. 
>
> Typically, when your choices are instances of a model, you would not 
> use ChoiceField, but ModelChoicefield. ModelChoiceField takes a 
> queryset when defining the form, and avoids evaluating the queryset 
> until the form is instantiated, which avoids the issue. The 
> documentation also explains how you can specify the queryset more 
> dynamically if that is required. 
>
> https://docs.djangoproject.com/en/1.8/ref/forms/fields/#modelchoicefield 
>
> (I'm assuming that the typo "choises" is only present in your email, 
> and your code correctly says "choices" and "ChoiceField") 
>
> Cheers 
>
> Tom 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/64b6f961-3ad5-4b06-ac35-a5590c9c1de5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: potential bug

['Tom Evans' via Django users]

On Sun, Jun 14, 2015 at 3:24 PM, Mark Nesterovych
 wrote:
> Hello.
> I've just finished small django site, and keep going on creating tests.
> I've found and issue with Model.objects.values_list  method.
> Looks like it disregard test database and looks into production one.
>
> Some details.
> I have a form with a filed customer =
> forms.ChoiseField(choises=Customer.objects.values_list('id', 'name'))
>
> When this form initing during tests, it loads data from production database.
>
> My test looks like this.
> class CustomerFormTest(TestCase):
> def setUp:
>  self.customer = Customer.objects.create(name='test name')
>
> def test_form_creation(self):
> form = CustomerLoginForm()
> self.assertIn('test name', form.as_ul())
>
>
> Assertion fails, and when I printing form content, I see select widget with
> options from production database objects.
>
> Can somebody confirm it's a bug ?
> Thank you.

It's not a bug. You are specifying the choices when the form is
defined, and at that point there is nothing in the database and so the
form has no choices. Since the field is never redefined in the form,
the choices will be whatever existed in the database when the form is
defined, which is a bad way of designing the form.

Typically, when your choices are instances of a model, you would not
use ChoiceField, but ModelChoicefield. ModelChoiceField takes a
queryset when defining the form, and avoids evaluating the queryset
until the form is instantiated, which avoids the issue. The
documentation also explains how you can specify the queryset more
dynamically if that is required.

https://docs.djangoproject.com/en/1.8/ref/forms/fields/#modelchoicefield

(I'm assuming that the typo "choises" is only present in your email,
and your code correctly says "choices" and "ChoiceField")

Cheers

Tom

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAFHbX1LerMfvVs056hVnFY8Jqm0gqtLDm0wcpWqgjC4V88fpBg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

potential bug

[Mark Nesterovych]

Hello.
I've just finished small django site, and keep going on creating tests.
I've found and issue with Model.objects.values_list  method.
Looks like it disregard test database and looks into production one.

Some details.
I have a form with a filed customer = 
forms.ChoiseField(choises=Customer.objects.values_list('id', 'name'))

When this form initing during tests, it loads data from production database.

My test looks like this.
class CustomerFormTest(TestCase):
def setUp:
 self.customer = Customer.objects.create(name='test name')

def test_form_creation(self):
form = CustomerLoginForm()
self.assertIn('test name', form.as_ul())


Assertion fails, and when I printing form content, I see select widget with 
options from production database objects.

Can somebody confirm it's a bug ?
Thank you.




-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/1cae35ab-e9c1-4870-8e7e-18c2b9e1c22a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: potential bug with defer() & only()

[Russell Keith-Magee]

Hi Will,

On Tue, Dec 23, 2014 at 3:56 PM, William Earp  wrote:
>
> Hi all,
>
> I'm writing some tests #18586) for defer() and only() and there appears to
> be a bug when it comes to chaining these two in a single query.
>
> If you look at the docs (
> https://docs.djangoproject.com/en/dev/ref/models/querysets/#django.db.models.query.QuerySet.only),
> it says this:
>
> # Final result is that everything except "headline" is 
> deferred.Entry.objects.only("headline", "body").defer("body")
> # Final result loads headline and body immediately (only() replaces any# 
> existing set of fields).
>
> Entry.objects.defer("body").only("headline", "body")
>
> However, when I test the last example "body" is still deferred after only() 
> has been applied to it. In a situation where there are only these two fields 
> in a model there should be no deferred field.
>
> Is there any reason for this or does this need reporting as a bug. If so, 
> what's the procedure for this?
>
> Well, either the code is wrong or the documentation is wrong, so
*something* needs to be changed. The documentation describes what I
understood to be Django's behavior, so it if isn't working like that, then
it sounds like you've found a bug.

To report it, visit

https://code.djangoproject.com

and on the top left, there's a "New ticket" button. (You may need to log in
first - either with your Github account, or by creating a Django Project
account).

Fill in the details (pretty much what you've done here, but also provide
Django + Python version numbers, and the database you're testing with), and
someone else will try to replicate the problem you describe.

Yours
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAJxq84-2_RcOND5GwL0d301QrLxXY3mhKbm6AWcb57P8QYATJg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

potential bug with defer() & only()

[William Earp]

Hi all,

I'm writing some tests #18586) for defer() and only() and there appears to 
be a bug when it comes to chaining these two in a single query.

If you look at the docs 
(https://docs.djangoproject.com/en/dev/ref/models/querysets/#django.db.models.query.QuerySet.only),
 
it says this:

# Final result is that everything except "headline" is 
deferred.Entry.objects.only("headline", "body").defer("body")
# Final result loads headline and body immediately (only() replaces any# 
existing set of fields).

Entry.objects.defer("body").only("headline", "body")

However, when I test the last example "body" is still deferred after only() has 
been applied to it. In a situation where there are only these two fields in a 
model there should be no deferred field. 

Is there any reason for this or does this need reporting as a bug. If so, 
what's the procedure for this?

Many thanks,

Will 

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/5a46bca6-3c88-4ac1-aa5b-5190d25895ec%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Potential Bug with hidden_intial_fields

[cs]

Hello,

while working on a mechanism for optimistic offline locking for django 
modelforms we discovered the following issue:


After a failed form validation this forms hidden_initial-fields (rendered 
via the field argument show_hidden_initial=True) will be rendered 
containing the submitted data of the corresponding regular fields not the 
data the hidden_initial_fields have submitted 
This might cause confusion because: if the form was not saved the value was 
not saved in the database but is now considered as current db-state in the 
hidden_initial_field
in addition if a succesive submit is triggered the form will now not 
identify a form.has_changed-event for the corresponding field


IMHO the hidden_initial_field should recieve its POST/GET data from the 
hidden_initial_field-data instead of the POST/GET data from the original 
field after a submit

The question is: Is this considered as a bug or is it just some feature not 
used the desired way

any comment on this are welcome

cs



A simplified way to reproduce this: 

-field ('label') has the argument show_hidden_initial=True
-open the view with an instance from the database
-change the value of the label field and save -> form will be declared 
invalid and form.label_initial will contain the new value despite that the 
form could not be saved
-in addition if save is clicked again the form is valid and 
form.changed_data will be empty


class MyModel(models.Model)
label = models.CharField()


class MyModelForm(forms.Form)
def __init__(*args, **kwargs):
super(MyModelForm, self).__init__(*args, **kwargs)
for f in self.fields.keys():
self.fields[f].show_hidden_initial = True

class Meta:
model = MyModel

  def clean(self):
cleaned_data = super(MyModelForm, self).clean()

if self.changed_data:
self._errors['label'] = ErrorList(['form has changed'])

return cleaned_data


def myView(request, modelId=None):

if modelId:
instance = MyModel.objects.get(pk=modelId)
else:
instance = None

if request.method == 'POST':
form = MyModelForm(request.POST, instance=instance)

if form.is_valid():
instance = form.save()
return HttpResponse('Success')
else:
form = MyModelForm(instance=instance)

template = '''{{form}}'''

t = template.Template(output)
c = template.Context({'form':form})
return t.render(c) 




-- 
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/-/Umu0mUELRvsJ.
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.

Re: Potential bug in [Typed]ChoiceField validation mechanism

[ethereon]

Forgot to add :

The problem can be avoided if both set of values are first normalized,
as :

>>> Decimal('0.50').normalize()
Decimal('0.5')

Perhaps this should be internally taken care of, instead of relying on
the user to normalize it?

On Nov 27, 1:04 pm, ethereon  wrote:
> In brief, a [Typed]ChoiceField can reject a valid choice of type
> Decimal because it is incorrectly compared using smart_unicode.
> Decimal('0.5')==Decimal('0.50') is true, while '0.5'=='0.50' is false.
>
> Verbosely, consider a model defined like so :
>
>     class Foo(models.Model):
>
>         BAR_CHOICES = (
>             (Decimal('0.25'), 'quarter'),
>             (Decimal('0.50'), 'unit')
>         )
>
>         bar = models.DecimalField(max_digits=4, decimal_places=2,
> choices = BAR_CHOICES)
>
> and a ModelForm based on it :
>
>     class FooForm(forms.ModelForm):
>
>         class Meta:
>             model = models.Foo
>
> Now :
>     >> FooForm({'bar':'0.50'}).is_valid()
>     true
>     >> FooForm({'bar':'0.5'}).is_valid()
>     false # errors = {'bar': [u'Select a valid choice. 0.5 is not one
> of the available choices.']}
>
> This issue might arise when the choices are dynamically generated, as
> Python isn't rigorous about trailing zeros :
>
>     >>> Decimal('1.0') + Decimal('0.5')
>     Decimal('1.5')
>     >>> Decimal('1.0') + Decimal('0.50')
>     Decimal('1.50')

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@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.

Potential bug in [Typed]ChoiceField validation mechanism

[ethereon]

In brief, a [Typed]ChoiceField can reject a valid choice of type
Decimal because it is incorrectly compared using smart_unicode.
Decimal('0.5')==Decimal('0.50') is true, while '0.5'=='0.50' is false.

Verbosely, consider a model defined like so :

class Foo(models.Model):

BAR_CHOICES = (
(Decimal('0.25'), 'quarter'),
(Decimal('0.50'), 'unit')
)

bar = models.DecimalField(max_digits=4, decimal_places=2,
choices = BAR_CHOICES)


and a ModelForm based on it :

class FooForm(forms.ModelForm):

class Meta:
model = models.Foo

Now :
>> FooForm({'bar':'0.50'}).is_valid()
true
>> FooForm({'bar':'0.5'}).is_valid()
false # errors = {'bar': [u'Select a valid choice. 0.5 is not one
of the available choices.']}


This issue might arise when the choices are dynamically generated, as
Python isn't rigorous about trailing zeros :

>>> Decimal('1.0') + Decimal('0.5')
Decimal('1.5')
>>> Decimal('1.0') + Decimal('0.50')
Decimal('1.50')

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@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.

Re: Email Backend setting needed, a potential bug

[Lakshman Prasad]

So, I see what has happened. (Interesting it is)

I upgraded django to 1.2 to try out:

$pip install --upgrade django

Then, back to work again:

$pip install django==1.1.2

I don't think pip removed the pyc files when replacing, which is making it
import mail module.

So, This problem should be solved if I removed all pycs. I did.

$find -name "*.pyc" -delete

I still have the same problem.

I am sure, I am using 1.1.1 right now, because in my view I do:

import django
django.get_version()

and it prints:
1.1.1

(This is no major problem, I know I can delete the entire folder and install
again. But it is interesting how it happened, which could be a bug in pip.)


On Wed, May 26, 2010 at 12:34 PM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:

> On Wed, May 26, 2010 at 2:54 AM, Lakshman Prasad 
> wrote:
> > Hi,
> > Since I upgraded to 1.1.2, I am unable to send mails as django seems
> > expecting a EMAIL_BACKEND.
>
> Something is severely broken with your setup, then. EMAIL_BACKEND is a
> setting that was introduced in Django 1.2, but it doesn't exist in
> 1.1.1 or 1.1.2.
>
> So - somehow you've managed to install Django 1.2, and that is what is
> being found by Python. Your stack trace also confirms this -
> django.core.mail is a module on Django 1.1.X, and a directory on 1.2.
> The stack trace you provide shows that you've got a directory.
>
> Yours,
> Russ Magee %-)
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-us...@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.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@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.

Re: Email Backend setting needed, a potential bug

[ankit rai]

check your django version .It might be that you have django at two places .I
m using django 1.1 , have not fount such problem

On Wed, May 26, 2010 at 12:34 PM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:

> On Wed, May 26, 2010 at 2:54 AM, Lakshman Prasad 
> wrote:
> > Hi,
> > Since I upgraded to 1.1.2, I am unable to send mails as django seems
> > expecting a EMAIL_BACKEND.
>
> Something is severely broken with your setup, then. EMAIL_BACKEND is a
> setting that was introduced in Django 1.2, but it doesn't exist in
> 1.1.1 or 1.1.2.
>
> So - somehow you've managed to install Django 1.2, and that is what is
> being found by Python. Your stack trace also confirms this -
> django.core.mail is a module on Django 1.1.X, and a directory on 1.2.
> The stack trace you provide shows that you've got a directory.
>
> Yours,
> Russ Magee %-)
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-us...@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.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@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.

Re: Email Backend setting needed, a potential bug

[Russell Keith-Magee]

On Wed, May 26, 2010 at 2:54 AM, Lakshman Prasad  wrote:
> Hi,
> Since I upgraded to 1.1.2, I am unable to send mails as django seems
> expecting a EMAIL_BACKEND.

Something is severely broken with your setup, then. EMAIL_BACKEND is a
setting that was introduced in Django 1.2, but it doesn't exist in
1.1.1 or 1.1.2.

So - somehow you've managed to install Django 1.2, and that is what is
being found by Python. Your stack trace also confirms this -
django.core.mail is a module on Django 1.1.X, and a directory on 1.2.
The stack trace you provide shows that you've got a directory.

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@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.

Email Backend setting needed, a potential bug

[Lakshman Prasad]

Hi,

Since I upgraded to 1.1.2, I am unable to send mails as django seems
expecting a EMAIL_BACKEND.

I tried to simply downgrade back to 1.1.1 not having to bother, but the
error continues.

I seems like a bug, but I don't know how it can be one, because, I cant see
how sending email can go untested.

Any pointers to what I am doing wrong, or if something is wrong in django,
appreciated. Thanks.

Following is the trraceback:

File "/usr/local/lib/python2.6/dist-packages/django/core/mail/__init__.py"
in send_mail
  59. fail_silently=fail_silently)
File "/usr/local/lib/python2.6/dist-packages/django/core/mail/__init__.py"
in get_connection
  29. path = backend or settings.EMAIL_BACKEND
File "/usr/local/lib/python2.6/dist-packages/django/utils/functional.py" in
__getattr__
  273. return getattr(self._wrapped, name)
Exception Type: AttributeError at /home/
Exception Value: 'Settings' object has no attribute 'EMAIL_BACKEND'

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@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.

Re: Django Contrib's UserCreationForm (Potential Bug)

[Sandman]

On 1/7/10 2:13 AM, Daniel Roseman wrote:
> On Jan 7, 4:36�am, Sandman  wrote:
>> Hi All,
>>
>> Happy new year.
>>
>> I've been using the svn version of django while developing a small app.
>> Yesterday after I updated the code, one of my tests started returning an
>> error. In fixing this error, I may have uncovered a bug but I can't be
>> sure if this is intentional behavior (I'm not really an experienced dev,
>> so no confidence :().
>>
>> Anyway, I have a UserCreationForm that inherits from
>> django.contrib.auth.forms.UserCreationForm (Code attached). In the
>> recent change to django code, a "clean" method was added to Contrib's
>> UserCreationForm. This method does not return any value. I think it is
>> supposed to return self.cleaned_data
>>
>> When my form (that delegates clean to super) tries to use cleaned_data
>> in the save(), an exception is raised since self.cleaned_data end up
>> being None.
>>
>> I have fixed the problem by adding a clean method in my form code that
>> delegates to "clean" of the ancestor of Contrib's UserCreationForm. But
>> it would be nice to simply inherit the form from contrib.auth and not
>> have to worry about the clean method.
>>
>> What do you think?
>>
>> Take care,
>> Rajiv.
>>
>> �forms.py
>> 2KViewDownload
> 
> Yes, this is a bug. It's already been raised in the issue tracker
> (#12520).
> 
> I must say that it's probably a bad idea to be developing against
> trunk at the moment. It's in quite a lot of flux as we approach 1.2,
> so unless you desperately need the latest features, I'd stay on 1.1
> for now.
> --
> DR.
> 
Thanks a lot for your replay Daniel. Yeah, I think I will revert to 1.1
for now to avoid heartache :)

Take care,
Rajiv.
-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@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.

Re: Django Contrib's UserCreationForm (Potential Bug)

[Daniel Roseman]

On Jan 7, 4:36 am, Sandman  wrote:
> Hi All,
>
> Happy new year.
>
> I've been using the svn version of django while developing a small app.
> Yesterday after I updated the code, one of my tests started returning an
> error. In fixing this error, I may have uncovered a bug but I can't be
> sure if this is intentional behavior (I'm not really an experienced dev,
> so no confidence :().
>
> Anyway, I have a UserCreationForm that inherits from
> django.contrib.auth.forms.UserCreationForm (Code attached). In the
> recent change to django code, a "clean" method was added to Contrib's
> UserCreationForm. This method does not return any value. I think it is
> supposed to return self.cleaned_data
>
> When my form (that delegates clean to super) tries to use cleaned_data
> in the save(), an exception is raised since self.cleaned_data end up
> being None.
>
> I have fixed the problem by adding a clean method in my form code that
> delegates to "clean" of the ancestor of Contrib's UserCreationForm. But
> it would be nice to simply inherit the form from contrib.auth and not
> have to worry about the clean method.
>
> What do you think?
>
> Take care,
> Rajiv.
>
>  forms.py
> 2KViewDownload

Yes, this is a bug. It's already been raised in the issue tracker
(#12520).

I must say that it's probably a bad idea to be developing against
trunk at the moment. It's in quite a lot of flux as we approach 1.2,
so unless you desperately need the latest features, I'd stay on 1.1
for now.
--
DR.
-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@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.

Django Contrib's UserCreationForm (Potential Bug)

[Sandman]

Hi All,

Happy new year.

I've been using the svn version of django while developing a small app.
Yesterday after I updated the code, one of my tests started returning an
error. In fixing this error, I may have uncovered a bug but I can't be
sure if this is intentional behavior (I'm not really an experienced dev,
so no confidence :().

Anyway, I have a UserCreationForm that inherits from
django.contrib.auth.forms.UserCreationForm (Code attached). In the
recent change to django code, a "clean" method was added to Contrib's
UserCreationForm. This method does not return any value. I think it is
supposed to return self.cleaned_data

When my form (that delegates clean to super) tries to use cleaned_data
in the save(), an exception is raised since self.cleaned_data end up
being None.

I have fixed the problem by adding a clean method in my form code that
delegates to "clean" of the ancestor of Contrib's UserCreationForm. But
it would be nice to simply inherit the form from contrib.auth and not
have to worry about the clean method.

What do you think?

Take care,
Rajiv.
from models import UserProfile
from django import forms
from django.utils.translation import ugettext_lazy as _
from django.contrib.auth.models import User, UNUSABLE_PASSWORD
from django.contrib.auth.forms import UserCreationForm as 
ContribUserCreationForm


class UserCreationForm(ContribUserCreationForm):
"""
Extends the form from django.contrib to include profile info.
"""
email = CommonFields().get_email_field()
full_name = CommonFields().get_full_name_field()
password2 = forms.CharField(
label=_("Confirm Password"), widget=forms.PasswordInput
)

class Meta(ContribUserCreationForm.Meta):
#
# Add new fields after the parent fields so that the new fields
# appear at the bottom
#
fields = (
'username',
'password1',
'password2',
'email',
'full_name',
)

#
# Avoid the lack of return value from ContribUserCreationForm
# by calling the grandparents clean().
#
def clean(self):
"""
Override the bug-ridden base class's clean method
"""
self.instance.password = UNUSABLE_PASSWORD
return super(ContribUserCreationForm, self).clean()

def save(self, user, commit=False):
"""
Save the new user into the database.
"""
user = super(UserCreationForm, self).save(commit=False)

user.set_password(self.cleaned_data['password1'])
user.email = self.cleaned_data['email']

if self.cleaned_data.has_key('full_name'):
user.first_name, user.last_name = CommonFields().split_full_name(
self.cleaned_data['full_name']
)
user.save()
#
# Create a profile for the new user.
#
profile = UserProfile(user=user)
profile.nickname = user.username
profile.theme_layout = ThemeChoices().get_default_theme()
profile.save()

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@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.