Re: annoyance with Python 3.2 support in Django 1.8

[Dan Stephenson]

Do we currently raise any warnings/exceptions in cases where Python support 
has / or is about to be dropped (particularly mid LTS)..   As a suggestion, 
I was thinking it could be helpful to people affected we raised exception 
msg indicating the last Django version to support their current Python 
version?I'd be happy to build if thought useful.




On Thursday, 3 December 2015 23:30:42 UTC, Chris Streeter wrote:
>
> Donald could probably provide more information, but this post from April 
> shows the Python 3.2 numbers downloading from PyPI are constant, and pretty 
> small [https://caremad.io/2015/04/a-year-of-pypi-downloads/] His take was 
> that CI systems (like Django's!) were doing most of the Python 3.2 package 
> downloading.
>
> On Thu, Dec 3, 2015 at 2:18 PM, Josh Smeaton  > wrote:
>
>> I agree with Tim. Unless someone puts their hand up to say they 
>> definitely require python 3.2 support for 1.8, I think it makes sense to 
>> drop support in the next dot release of 1.8. 3.2 isn't an easy python to 
>> find in the wild as far as I know, so I'd be surprised if there was any 
>> real support for it on 1.8 by users.
>>
>> On Friday, 4 December 2015 02:50:24 UTC+11, Tim Graham wrote:
>>>
>>> No, using pypy3 doesn't make things easier. There are a handful of test 
>>> failures with pypy3 and it doesn't solve the issue that 
>>> unittest-xml-reporting doesn't work with Python 3.2.
>>>
>>> Issues aside, the main thing I'm trying to find out is, are we providing 
>>> any substantial value supporting Django on an unsupported version of 
>>> Python? So far no one has indicated "yes". If you care about Django 
>>> security updates, shouldn't you care about Python security updates too?
>>>
>>> On Wednesday, December 2, 2015 at 5:22:46 PM UTC-5, Shai Berger wrote:

 On Wednesday 02 December 2015 21:05:00 Tim Graham wrote: 
 > 
 > Given that no one reading this indicated that they plan a long-term 
 > deployment of Python 3.2, how about if in the next 1.8.x release we 
 > advertise that Python 3.2 support for Django 1.8 will end January 1, 
 2017? 
 > (we won't break anything intentionally after that, but we won't have 
 to 
 > worry about testing and can spin down our 12.04 machine before it's 
 EOL a 
 > few months later) 
 > 

 Since you brought the issue up yourself -- shouldn't we "swap" PyPy3 
 for 
 Python 3.2? Would that make running tests on ubuntu 14.04 easier? 

 Just a half-baked thought, 

 Shai. 

>>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-develop...@googlegroups.com .
>> To post to this group, send email to django-d...@googlegroups.com 
>> .
>> Visit this group at http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/0a0631c3-4733-46fc-8884-c4050c8b8701%40googlegroups.com
>>  
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/933a22e5-3f88-4663-b25a-9fdedc83d9c1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: annoyance with Python 3.2 support in Django 1.8

[Chris Streeter]

Donald could probably provide more information, but this post from April
shows the Python 3.2 numbers downloading from PyPI are constant, and pretty
small [https://caremad.io/2015/04/a-year-of-pypi-downloads/] His take was
that CI systems (like Django's!) were doing most of the Python 3.2 package
downloading.

On Thu, Dec 3, 2015 at 2:18 PM, Josh Smeaton  wrote:

> I agree with Tim. Unless someone puts their hand up to say they definitely
> require python 3.2 support for 1.8, I think it makes sense to drop support
> in the next dot release of 1.8. 3.2 isn't an easy python to find in the
> wild as far as I know, so I'd be surprised if there was any real support
> for it on 1.8 by users.
>
> On Friday, 4 December 2015 02:50:24 UTC+11, Tim Graham wrote:
>>
>> No, using pypy3 doesn't make things easier. There are a handful of test
>> failures with pypy3 and it doesn't solve the issue that
>> unittest-xml-reporting doesn't work with Python 3.2.
>>
>> Issues aside, the main thing I'm trying to find out is, are we providing
>> any substantial value supporting Django on an unsupported version of
>> Python? So far no one has indicated "yes". If you care about Django
>> security updates, shouldn't you care about Python security updates too?
>>
>> On Wednesday, December 2, 2015 at 5:22:46 PM UTC-5, Shai Berger wrote:
>>>
>>> On Wednesday 02 December 2015 21:05:00 Tim Graham wrote:
>>> >
>>> > Given that no one reading this indicated that they plan a long-term
>>> > deployment of Python 3.2, how about if in the next 1.8.x release we
>>> > advertise that Python 3.2 support for Django 1.8 will end January 1,
>>> 2017?
>>> > (we won't break anything intentionally after that, but we won't have
>>> to
>>> > worry about testing and can spin down our 12.04 machine before it's
>>> EOL a
>>> > few months later)
>>> >
>>>
>>> Since you brought the issue up yourself -- shouldn't we "swap" PyPy3 for
>>> Python 3.2? Would that make running tests on ubuntu 14.04 easier?
>>>
>>> Just a half-baked thought,
>>>
>>> Shai.
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/0a0631c3-4733-46fc-8884-c4050c8b8701%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: annoyance with Python 3.2 support in Django 1.8

[Josh Smeaton]

I agree with Tim. Unless someone puts their hand up to say they definitely 
require python 3.2 support for 1.8, I think it makes sense to drop support 
in the next dot release of 1.8. 3.2 isn't an easy python to find in the 
wild as far as I know, so I'd be surprised if there was any real support 
for it on 1.8 by users.

On Friday, 4 December 2015 02:50:24 UTC+11, Tim Graham wrote:
>
> No, using pypy3 doesn't make things easier. There are a handful of test 
> failures with pypy3 and it doesn't solve the issue that 
> unittest-xml-reporting doesn't work with Python 3.2.
>
> Issues aside, the main thing I'm trying to find out is, are we providing 
> any substantial value supporting Django on an unsupported version of 
> Python? So far no one has indicated "yes". If you care about Django 
> security updates, shouldn't you care about Python security updates too?
>
> On Wednesday, December 2, 2015 at 5:22:46 PM UTC-5, Shai Berger wrote:
>>
>> On Wednesday 02 December 2015 21:05:00 Tim Graham wrote: 
>> > 
>> > Given that no one reading this indicated that they plan a long-term 
>> > deployment of Python 3.2, how about if in the next 1.8.x release we 
>> > advertise that Python 3.2 support for Django 1.8 will end January 1, 
>> 2017? 
>> > (we won't break anything intentionally after that, but we won't have to 
>> > worry about testing and can spin down our 12.04 machine before it's EOL 
>> a 
>> > few months later) 
>> > 
>>
>> Since you brought the issue up yourself -- shouldn't we "swap" PyPy3 for 
>> Python 3.2? Would that make running tests on ubuntu 14.04 easier? 
>>
>> Just a half-baked thought, 
>>
>> Shai. 
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0a0631c3-4733-46fc-8884-c4050c8b8701%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: worth adding PyPy to continuous integration?

[Markus Holtermann]

Hey Tim,

I think we should at least run the tests occasionally and see if they pass and 
if not see how much effort it takes to fix problems.

Regarding the migration date issues, I fixed them in newer PyPy versions: 
https://bitbucket.org/pypy/pypy/issues/2062/inconsistency-in-__repr__-for-date-time

/Markus

On December 3, 2015 2:46:38 AM GMT+10:00, Tim Graham  
wrote:
>Once in a while, we get a ticket about failures when running the Django
>
>test suite on PyPy. Sometimes they are bugs in PyPy, other times we use
>
>something that's not available or behaves differently in PyPy. Is it
>worth 
>adding PyPy to our continuous integration so we can proactively address
>
>these issues?
>
>(We can't test with pypy3 since that's based on Python 3.2 which we've 
>dropped support for in Django 1.9.)
>
>Recent tickets:
>https://code.djangoproject.com/ticket/24779
>https://code.djangoproject.com/ticket/25844
>
>Current failures with pypy 2.4.0 and Django 1.9:
>
>==
>ERROR: test_serialize_datetime (migrations.test_writer.WriterTests)
>--
>Traceback (most recent call last):
>File "/home/tim/code/django/tests/migrations/test_writer.py", line 248,
>
>in test_serialize_datetime
>self.assertSerializedEqual(datetime.datetime.utcnow)
>File "/home/tim/code/django/tests/migrations/test_writer.py", line 179,
>
>in assertSerializedEqual
>self.assertEqual(self.serialize_round_trip(value), value)
>File "/home/tim/code/django/tests/migrations/test_writer.py", line 175,
>
>in serialize_round_trip
>string, imports = MigrationWriter.serialize(value)
>File "/home/tim/code/django/django/db/migrations/writer.py", line 540,
>in 
>serialize
>"topics/migrations/#migration-serializing" % (value,
>get_docs_version())
>ValueError: Cannot serialize: 'datetime.datetime'>>
>There are some values Django cannot serialize into migration files.
>For more, see 
>https://docs.djangoproject.com/en/dev/topics/migrations/#migration-serializing
>
>==
>ERROR: test_simple_migration (migrations.test_writer.WriterTests)
>--
>Traceback (most recent call last):
>File "/home/tim/code/django/tests/migrations/test_writer.py", line 459,
>
>in test_simple_migration
>output = writer.as_string()
>File "/home/tim/code/django/django/db/migrations/writer.py", line 167,
>in 
>as_string
>operation_string, operation_imports = 
>OperationWriter(operation).serialize()
>File "/home/tim/code/django/django/db/migrations/writer.py", line 124,
>in 
>serialize
>_write(arg_name, arg_value)
>File "/home/tim/code/django/django/db/migrations/writer.py", line 76,
>in 
>_write
>arg_string, arg_imports = MigrationWriter.serialize(item)
>File "/home/tim/code/django/django/db/migrations/writer.py", line 357,
>in 
>serialize
>item_string, item_imports = cls.serialize(item)
>File "/home/tim/code/django/django/db/migrations/writer.py", line 433,
>in 
>serialize
>return cls.serialize_deconstructed(path, args, kwargs)
>File "/home/tim/code/django/django/db/migrations/writer.py", line 318,
>in 
>serialize_deconstructed
>arg_string, arg_imports = cls.serialize(arg)
>File "/home/tim/code/django/django/db/migrations/writer.py", line 540,
>in 
>serialize
>"topics/migrations/#migration-serializing" % (value,
>get_docs_version())
>ValueError: Cannot serialize: 'datetime.datetime'>>
>There are some values Django cannot serialize into migration files.
>For more, see 
>https://docs.djangoproject.com/en/dev/topics/migrations/#migration-serializing
>
>==
>ERROR: test_band_data_setters 
>(gis_tests.gdal_tests.test_raster.GDALBandTests)
>--
>Traceback (most recent call last):
>File "/home/tim/code/django/tests/gis_tests/gdal_tests/test_raster.py",
>
>line 357, in test_band_data_setters
>bandmem.data(packed_block, (1, 1), (2, 2))
>File "/home/tim/code/django/django/contrib/gis/gdal/raster/band.py",
>line 
>133, in data
>data_array = ctypes_array.from_buffer_copy(data)
>AttributeError: type object 'c_ubyte_Array_4' has no attribute 
>'from_buffer_copy'
>
>==
>FAIL: test_prefetch_related_queryset
>(model_forms.tests.OtherModelFormTests)
>--
>Traceback (most recent call last):
>File "/home/tim/code/django/tests/model_forms/tests.py", line 2308, in 
>test_prefetch_related_queryset
>(red_item.pk, 'red'),
>  File "/home/tim/code/django/django/test/testcases.py", line 93, in 
>__exit__
>query['sql'] for query in self.captured_queries
>AssertionError: 2 queries executed, 4 expected
>Captured queries were:
>SELECT "model_forms_c

Re: Referrer Policy Delivery, Django shouldn't do strict referrer check anymore?

[Flávio Junior]

Florian, then Django will have to keep this limitation: can't use a global 
no-referrer policy on HTTPS because of strict referrer check. Correct? 
Should I create an issue to keep this logged?

Em quinta-feira, 3 de dezembro de 2015 13:19:38 UTC-3, Florian Apolloner 
escreveu:
>
>
>
> On Wednesday, December 2, 2015 at 7:37:30 PM UTC+1, Flávio Junior wrote:
>>
>> If Django still needs 
>>  the strict 
>> referrer check, maybe a better error message should be implemented.
>>
>
> I do not see any reason why it would not need it anymore. Django needs to 
> ensure that the request came from a "trusted origin", therefore we still 
> need it.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/cfbe3a2a-a20f-4691-8eb9-9306bf178a6d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Validation of m2m

[Tim Graham]

Here's an open ticket about adding model level validation for many-to-many: 
https://code.djangoproject.com/ticket/12938

On Thursday, December 3, 2015 at 11:04:22 AM UTC-5, Federico Capoano wrote:
>
> Thanks Aymeric,
>
> I decided to post this problem on django-developers because I've read this 
> ticket:
> https://code.djangoproject.com/ticket/24731
> Sorry for omitting this information.
>
> Has there been a discussion about this topic already?
>
> Would it be hard to implement an easier solution into django?
>
> I spent a few hours working on this issue, I consider myself fluent with 
> django and it's quite shocking I had to put such an amount of effort just 
> to validate many2many relationships before they are saved to the database.
>
> IMHO it would be better if we could do one of these two (or even both) 
> things:
>
> 1. make this process easier in future django versions
> 2. document the current best practice to solve this problem in current 
> django to save people's time
>
> What do people you think?
>
> Here's my solution working with django 1.9:
> https://github.com/openwisp/django-netjsonconfig/compare/4082988...master
>
> What do you think of it? Can it be improved in some way?
>
> Federico
>
>
> On Thursday, December 3, 2015 at 1:43:21 PM UTC+1, Aymeric Augustin wrote:
>>
>> Hello Frederico,
>>
>> It appears that you're hitting the problem described in the "Avoid 
>> catching exceptions inside atomic!" warning on this page:
>>
>> https://docs.djangoproject.com/en/1.8/topics/db/transactions/#handling-exceptions-within-postgresql-transactions
>>
>> To obtain that sort of result, I suppose you must be catching an 
>> IntegrityError, re-raising a ValidationError, which Django in turn catches, 
>> and then you hit that traceback.
>>
>> Adding an atomic block inside your try/catch block that catches the 
>> IntegrityError will resolve that particular problem — putting that part of 
>> the discussion into django-users territory.
>>
>> If this isn't what happens, please post your code and ask for help on 
>> django-users.
>>
>> -- 
>> Aymeric
>>
>> 2015-12-03 13:28 GMT+01:00 Federico Capoano :
>>
>>> Hi everybody,
>>>
>>> I am sure it has happened to many of you.
>>>
>>> Validating m2m BEFORE saving the relationships is very hard and time 
>>> consuming.
>>>
>>> Now this solution:
>>> http://schinckel.net/2012/02/06/pre-validating-many-to-many-fields./
>>>
>>> Proposes to solve it with a ModelForm in the admin.
>>> Cool, that works.
>>>
>>> But, if I want to enforce validation on the model, to avoid corrupted 
>>> data, I notice the signal is executed in a transaction block, in which if I 
>>> raise a ValidationError I get the following:
>>>
>>> Traceback (most recent call last):
>>>   File 
>>> "/var/www/django-netjsonconfig/django_netjsonconfig/tests/test_device.py", 
>>> line 106, in test_m2m_validation
>>> d.templates.add(t)
>>>   File 
>>> "/home/nemesis/.virtualenvs/djnetconfig3/lib/python3.4/site-packages/django/db/models/fields/related_descriptors.py",
>>>  
>>> line 843, in add
>>> self._add_items(self.source_field_name, self.target_field_name, 
>>> *objs)
>>>   File 
>>> "/home/nemesis/.virtualenvs/djnetconfig3/lib/python3.4/site-packages/sortedm2m/fields.py",
>>>  
>>> line 138, in _add_items
>>> for val in vals:
>>>   File 
>>> "/home/nemesis/.virtualenvs/djnetconfig3/lib/python3.4/site-packages/django/db/models/query.py",
>>>  
>>> line 258, in __iter__
>>> self._fetch_all()
>>>   File 
>>> "/home/nemesis/.virtualenvs/djnetconfig3/lib/python3.4/site-packages/django/db/models/query.py",
>>>  
>>> line 1074, in _fetch_all
>>> self._result_cache = list(self.iterator())
>>>   File 
>>> "/home/nemesis/.virtualenvs/djnetconfig3/lib/python3.4/site-packages/django/db/models/query.py",
>>>  
>>> line 158, in __iter__
>>> for row in compiler.results_iter():
>>>   File 
>>> "/home/nemesis/.virtualenvs/djnetconfig3/lib/python3.4/site-packages/django/db/models/sql/compiler.py",
>>>  
>>> line 806, in results_iter
>>> results = self.execute_sql(MULTI)
>>>   File 
>>> "/home/nemesis/.virtualenvs/djnetconfig3/lib/python3.4/site-packages/django/db/models/sql/compiler.py",
>>>  
>>> line 852, in execute_sql
>>> cursor.execute(sql, params)
>>>   File 
>>> "/home/nemesis/.virtualenvs/djnetconfig3/lib/python3.4/site-packages/django/db/backends/utils.py",
>>>  
>>> line 59, in execute
>>> self.db.validate_no_broken_transaction()
>>>   File 
>>> "/home/nemesis/.virtualenvs/djnetconfig3/lib/python3.4/site-packages/django/db/backends/base/base.py",
>>>  
>>> line 429, in validate_no_broken_transaction
>>> "An error occurred in the current transaction. You can't "
>>> django.db.transaction.TransactionManagementError: An error occurred in 
>>> the current transaction. You can't execute queries until the end of the 
>>> 'atomic' block.
>>>
>>> This is surely an area that needs improvement in django.
>>>
>>> Why is it so hard?
>>>
>>> Best regards
>>> Federico
>>>
>>> -- 
>

Re: Referrer Policy Delivery, Django shouldn't do strict referrer check anymore?

[Florian Apolloner]

On Wednesday, December 2, 2015 at 7:37:30 PM UTC+1, Flávio Junior wrote:
>
> If Django still needs 
>  the strict 
> referrer check, maybe a better error message should be implemented.
>

I do not see any reason why it would not need it anymore. Django needs to 
ensure that the request came from a "trusted origin", therefore we still 
need it.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/baa078e5-c55e-4294-bd75-11fce7e553a1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Possible bug transaction rollback or SQLite backend

[Carl Meyer]

Hi Jonas,

On 12/03/2015 07:02 AM, Jonas H wrote:
> Hi there,
> 
> there seems to be something wrong with either the SQLite backend, the
> SQLite library itself or Django's transaction handling. Whenever I try
> to run the test suite of a specific project of mine
> (https://github.com/jonashaag/fahrtkostenrechner), using
> `fahrtkostenrechner/manage.py test events`, it shows the following behavior:
> 
> * On Linux, it doesn't crash and shows actual test failures.
> * On OSX, with SQLite's in-memory database as test database, a segfault
> (!) occurs. (I'm not familiar with the lower-level Python SQLite
> bindings, but I guess a segfault should *never* happen in the first place?!)

Certainly a segfault should not happen :-) The fact that one is even
possible does point to a bug in Python's sqlite module (AFAIK any case
where one can trigger a segfault from pure Python code is considered a
bug in CPython). It may be that we can avoid triggering this particular
segfault bug, if we can figure out how we are triggering it.

I'd be extremely surprised to find _two_ segfault bugs in the SQLite
bindings (that both occur only on OS X) so it seems almost certain to me
that https://code.djangoproject.com/ticket/24080 is the same underlying
issue one way or another.

> * On OSX, with a on-disk test database, a
> "django.db.utils.ProgrammingError: Cannot operate on a closed database."
> (caused by `_cursor()`:
> https://github.com/django/django/blob/4d0f8831a7498ab3b1ebcf4cafa2ee234503e4f8/django/db/backends/base/base.py#L206)
> occurs.

That's a useful clue! If it consistently tracks with the segfault, where
the only difference is on-disk vs memory db, it seems likely that it's
the same situation that's causing a segfault in the memory-db case.

> It looks to me that the cause of this is some unfinished transaction
> rollback, but I'm not sure, so I'm asking for guidance here. In the file
> linked above in L193, is it legitimate for `needs_rollback` to  be True?
> In my debugging I found `connection != None` and `needs_rollback=True`
> whenever `_cursor()` fails in L206, so I figured maybe there might be an
> outstanding rollback for some reason?

`connection != None` and `needs_rollback = True` is a legitimate state
for the connection to be in when someone asks for a cursor, AFAIK. It
would be most useful to trace back and find out a) what caused
`needs_rollback` to be set to `True`, and b) when/how/why was the
database closed?

> I use Python 3.5, SQLite 3.9.2 and I can reproduce the crash on Django
>>=1.8.4,<1.9.

This might be useful information to add to
https://code.djangoproject.com/ticket/24080, if it's not already present
there.

Does the version range you give imply that the issue goes away in Django
1.9, or just that you've never tried it there?

Carl

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


signature.asc
Description: OpenPGP digital signature

Re: Validation of m2m

[Federico Capoano]

Thanks Aymeric,

I decided to post this problem on django-developers because I've read this 
ticket:
https://code.djangoproject.com/ticket/24731
Sorry for omitting this information.

Has there been a discussion about this topic already?

Would it be hard to implement an easier solution into django?

I spent a few hours working on this issue, I consider myself fluent with 
django and it's quite shocking I had to put such an amount of effort just 
to validate many2many relationships before they are saved to the database.

IMHO it would be better if we could do one of these two (or even both) 
things:

1. make this process easier in future django versions
2. document the current best practice to solve this problem in current 
django to save people's time

What do people you think?

Here's my solution working with django 1.9:
https://github.com/openwisp/django-netjsonconfig/compare/4082988...master

What do you think of it? Can it be improved in some way?

Federico


On Thursday, December 3, 2015 at 1:43:21 PM UTC+1, Aymeric Augustin wrote:
>
> Hello Frederico,
>
> It appears that you're hitting the problem described in the "Avoid 
> catching exceptions inside atomic!" warning on this page:
>
> https://docs.djangoproject.com/en/1.8/topics/db/transactions/#handling-exceptions-within-postgresql-transactions
>
> To obtain that sort of result, I suppose you must be catching an 
> IntegrityError, re-raising a ValidationError, which Django in turn catches, 
> and then you hit that traceback.
>
> Adding an atomic block inside your try/catch block that catches the 
> IntegrityError will resolve that particular problem — putting that part of 
> the discussion into django-users territory.
>
> If this isn't what happens, please post your code and ask for help on 
> django-users.
>
> -- 
> Aymeric
>
> 2015-12-03 13:28 GMT+01:00 Federico Capoano  >:
>
>> Hi everybody,
>>
>> I am sure it has happened to many of you.
>>
>> Validating m2m BEFORE saving the relationships is very hard and time 
>> consuming.
>>
>> Now this solution:
>> http://schinckel.net/2012/02/06/pre-validating-many-to-many-fields./
>>
>> Proposes to solve it with a ModelForm in the admin.
>> Cool, that works.
>>
>> But, if I want to enforce validation on the model, to avoid corrupted 
>> data, I notice the signal is executed in a transaction block, in which if I 
>> raise a ValidationError I get the following:
>>
>> Traceback (most recent call last):
>>   File 
>> "/var/www/django-netjsonconfig/django_netjsonconfig/tests/test_device.py", 
>> line 106, in test_m2m_validation
>> d.templates.add(t)
>>   File 
>> "/home/nemesis/.virtualenvs/djnetconfig3/lib/python3.4/site-packages/django/db/models/fields/related_descriptors.py",
>>  
>> line 843, in add
>> self._add_items(self.source_field_name, self.target_field_name, *objs)
>>   File 
>> "/home/nemesis/.virtualenvs/djnetconfig3/lib/python3.4/site-packages/sortedm2m/fields.py",
>>  
>> line 138, in _add_items
>> for val in vals:
>>   File 
>> "/home/nemesis/.virtualenvs/djnetconfig3/lib/python3.4/site-packages/django/db/models/query.py",
>>  
>> line 258, in __iter__
>> self._fetch_all()
>>   File 
>> "/home/nemesis/.virtualenvs/djnetconfig3/lib/python3.4/site-packages/django/db/models/query.py",
>>  
>> line 1074, in _fetch_all
>> self._result_cache = list(self.iterator())
>>   File 
>> "/home/nemesis/.virtualenvs/djnetconfig3/lib/python3.4/site-packages/django/db/models/query.py",
>>  
>> line 158, in __iter__
>> for row in compiler.results_iter():
>>   File 
>> "/home/nemesis/.virtualenvs/djnetconfig3/lib/python3.4/site-packages/django/db/models/sql/compiler.py",
>>  
>> line 806, in results_iter
>> results = self.execute_sql(MULTI)
>>   File 
>> "/home/nemesis/.virtualenvs/djnetconfig3/lib/python3.4/site-packages/django/db/models/sql/compiler.py",
>>  
>> line 852, in execute_sql
>> cursor.execute(sql, params)
>>   File 
>> "/home/nemesis/.virtualenvs/djnetconfig3/lib/python3.4/site-packages/django/db/backends/utils.py",
>>  
>> line 59, in execute
>> self.db.validate_no_broken_transaction()
>>   File 
>> "/home/nemesis/.virtualenvs/djnetconfig3/lib/python3.4/site-packages/django/db/backends/base/base.py",
>>  
>> line 429, in validate_no_broken_transaction
>> "An error occurred in the current transaction. You can't "
>> django.db.transaction.TransactionManagementError: An error occurred in 
>> the current transaction. You can't execute queries until the end of the 
>> 'atomic' block.
>>
>> This is surely an area that needs improvement in django.
>>
>> Why is it so hard?
>>
>> Best regards
>> Federico
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-develop...@googlegroups.com .
>> To post to this group, send email to django-d...@googlegroups.com 
>> .
>> Visit this grou

Re: Possible bug transaction rollback or SQLite backend

[Jonas H]

Tim,

thanks for the pointer. I'm not sure if my issue is related. I've found a 
minimal example for another (same?) 
issue: https://code.djangoproject.com/ticket/25860

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/19ad9d9d-1ea0-4a9a-a280-3b02ff3b2320%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: annoyance with Python 3.2 support in Django 1.8

[Tim Graham]

No, using pypy3 doesn't make things easier. There are a handful of test 
failures with pypy3 and it doesn't solve the issue that 
unittest-xml-reporting doesn't work with Python 3.2.

Issues aside, the main thing I'm trying to find out is, are we providing 
any substantial value supporting Django on an unsupported version of 
Python? So far no one has indicated "yes". If you care about Django 
security updates, shouldn't you care about Python security updates too?

On Wednesday, December 2, 2015 at 5:22:46 PM UTC-5, Shai Berger wrote:
>
> On Wednesday 02 December 2015 21:05:00 Tim Graham wrote: 
> > 
> > Given that no one reading this indicated that they plan a long-term 
> > deployment of Python 3.2, how about if in the next 1.8.x release we 
> > advertise that Python 3.2 support for Django 1.8 will end January 1, 
> 2017? 
> > (we won't break anything intentionally after that, but we won't have to 
> > worry about testing and can spin down our 12.04 machine before it's EOL 
> a 
> > few months later) 
> > 
>
> Since you brought the issue up yourself -- shouldn't we "swap" PyPy3 for 
> Python 3.2? Would that make running tests on ubuntu 14.04 easier? 
>
> Just a half-baked thought, 
>
> Shai. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/cfb4a4e9-c415-4c67-8408-7440a7c314f8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: worth adding PyPy to continuous integration?

[Tim Graham]

Yes, exactly Josh. I was hoping someone familiar with pypy could offer some 
insight. I think we can only add continuous integration support if at least 
a couple champion the effort and make themselves available to help with 
issues as they arise. As far as I know, we don't currently have this 
expertise on the Django team. It seems like at least a few people are using 
Django on pypy with at least some success (actually our docs say Django is 
compatible [1]).

[1] https://docs.djangoproject.com/en/dev/topics/performance/#id1

Those test failures I posted are with pypy 2.4.0 which I installed sometime 
ago. With the latest version pypy 4.0.1 the test aborts part way through 
with:

Python traceback:
  File "pypy_module_pypyjit_interp_jit.c", line 102, in 
jump_absolute__AccessDirect_None
  File "rpython_jit_metainterp_warmstate.c", line 17762, in 
maybe_compile_and_run__star_5_1
  File "rpython_jit_metainterp_warmstate.c", line 46755, in 
bound_reached__star_5_1
  File "rpython_jit_metainterp_pyjitpl.c", line 18015, in 
compile_and_run_once___rpython_jit_metainterp_ji_23
  File "rpython_jit_metainterp_pyjitpl.c", line 4721, in 
MetaInterp__compile_and_run_once
  File "rpython_jit_metainterp_pyjitpl.c", line 19485, in 
MetaInterp_interpret
  File "rpython_jit_metainterp_pyjitpl.c", line 32873, in 
MetaInterp__interpret
  File "rpython_jit_metainterp_pyjitpl.c", line 48286, in 
MIFrame_run_one_step
  File "rpython_jit_metainterp_pyjitpl_2.c", line 4858, in 
MIFrame_opimpl_jit_merge_point
  File "rpython_jit_metainterp_pyjitpl_2.c", line 59878, in 
MetaInterp_reached_loop_header
  File "rpython_jit_metainterp_pyjitpl_3.c", line 30731, in 
MetaInterp_compile_loop
  File "rpython_jit_metainterp_compile.c", line 11591, in compile_loop
  File "rpython_jit_metainterp_optimizeopt___init__.c", line 224, in 
optimize_trace
  File "rpython_jit_metainterp_optimizeopt_unroll.c", line 5499, in 
UnrollOptimizer_optimize_peeled_loop
  File "rpython_jit_metainterp_optimizeopt_unroll.c", line 17039, in 
UnrollOptimizer_jump_to_existing_trace
  File "rpython_jit_metainterp_optimizeopt_unroll.c", line 22464, in 
UnrollOptimizer_inline_short_preamble
  File "rpython_jit_metainterp_optimizeopt_unroll.c", line 24548, in 
UnrollOptimizer__map_args
~~~ Crash in JIT! 
Aborted (core dumped)

On Thursday, December 3, 2015 at 12:56:50 AM UTC-5, Josh Smeaton wrote:
>
> Shouldn't we decide if we want to support pypy first? By putting it on CI 
> that's an implicit agreement to support pypy potentially at the cost of 
> certain features.
>
> There's also the consideration that python2 is going away in django 2.0, 
> so if pypy3 isn't up to date wrt python3, we'd have to drop pypy.
>
> On Thursday, 3 December 2015 03:52:24 UTC+11, Marc Tamlyn wrote:
>>
>> If we can get it running on the CI reasonably easily I see no reason why 
>> not.
>>
>> On 2 December 2015 at 16:46, Tim Graham  wrote:
>>
>>> Once in a while, we get a ticket about failures when running the Django 
>>> test suite on PyPy. Sometimes they are bugs in PyPy, other times we use 
>>> something that's not available or behaves differently in PyPy. Is it worth 
>>> adding PyPy to our continuous integration so we can proactively address 
>>> these issues?
>>>
>>> (We can't test with pypy3 since that's based on Python 3.2 which we've 
>>> dropped support for in Django 1.9.)
>>>
>>> Recent tickets:
>>> https://code.djangoproject.com/ticket/24779
>>> https://code.djangoproject.com/ticket/25844
>>>
>>> Current failures with pypy 2.4.0 and Django 1.9:
>>>
>>> ==
>>> ERROR: test_serialize_datetime (migrations.test_writer.WriterTests)
>>> --
>>> Traceback (most recent call last):
>>>   File "/home/tim/code/django/tests/migrations/test_writer.py", line 
>>> 248, in test_serialize_datetime
>>> self.assertSerializedEqual(datetime.datetime.utcnow)
>>>   File "/home/tim/code/django/tests/migrations/test_writer.py", line 
>>> 179, in assertSerializedEqual
>>> self.assertEqual(self.serialize_round_trip(value), value)
>>>   File "/home/tim/code/django/tests/migrations/test_writer.py", line 
>>> 175, in serialize_round_trip
>>> string, imports = MigrationWriter.serialize(value)
>>>   File "/home/tim/code/django/django/db/migrations/writer.py", line 540, 
>>> in serialize
>>> "topics/migrations/#migration-serializing" % (value, 
>>> get_docs_version())
>>> ValueError: Cannot serialize: >> 'datetime.datetime'>>
>>> There are some values Django cannot serialize into migration files.
>>> For more, see 
>>> https://docs.djangoproject.com/en/dev/topics/migrations/#migration-serializing
>>>
>>> ==
>>> ERROR: test_simple_migration (migrations.test_writer.WriterTests)
>>> --
>>> Traceback (most recent call last):
>>>   F

Re: Possible bug transaction rollback or SQLite backend

[Tim Graham]

Hi Jonas, I wonder if https://code.djangoproject.com/ticket/24080 might be 
related. If you could distill the project you linked into a minimal example 
to reproduce that would be ideal. By the way, "is it a bug?" questions 
normally go to django-users. Tim

On Thursday, December 3, 2015 at 9:02:54 AM UTC-5, Jonas H wrote:
>
> Hi there,
>
> there seems to be something wrong with either the SQLite backend, the 
> SQLite library itself or Django's transaction handling. Whenever I try to 
> run the test suite of a specific project of mine (
> https://github.com/jonashaag/fahrtkostenrechner), using 
> `fahrtkostenrechner/manage.py test events`, it shows the following behavior:
>
> * On Linux, it doesn't crash and shows actual test failures.
> * On OSX, with SQLite's in-memory database as test database, a segfault 
> (!) occurs. (I'm not familiar with the lower-level Python SQLite bindings, 
> but I guess a segfault should *never* happen in the first place?!)
> * On OSX, with a on-disk test database, a 
> "django.db.utils.ProgrammingError: Cannot operate on a closed database." 
> (caused by `_cursor()`: 
> https://github.com/django/django/blob/4d0f8831a7498ab3b1ebcf4cafa2ee234503e4f8/django/db/backends/base/base.py#L206)
>  
> occurs.
>
> It looks to me that the cause of this is some unfinished transaction 
> rollback, but I'm not sure, so I'm asking for guidance here. In the file 
> linked above in L193, is it legitimate for `needs_rollback` to  be True? In 
> my debugging I found `connection != None` and `needs_rollback=True` 
> whenever `_cursor()` fails in L206, so I figured maybe there might be an 
> outstanding rollback for some reason?
>
> I use Python 3.5, SQLite 3.9.2 and I can reproduce the crash on Django 
> >=1.8.4,<1.9.
>
> Jonas
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/32892c49-b999-4b23-a107-334dfb6b9d41%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Referrer Policy Delivery, Django shouldn't do strict referrer check anymore?

[Flávio Junior]

That won't solve the problem.
If you set policy to *No Referrer* and make a request to the same origin, 
Chrome sets Origin to "null", Firefox doesn't set the header and Safari 
sets the correct origin.

Em quarta-feira, 2 de dezembro de 2015 16:01:51 UTC-3, Collin Anderson 
escreveu:
>
> Seems to me we could ignore the referrer if we get a valid same-domain 
> Origin header.
>
> On Wed, Dec 2, 2015 at 1:29 PM, Flávio Junior  > wrote:
>
>> Some browsers already implement the Referrer Policy draft 
>> , 
>> which gives the developer more control over the referer HTTP header sent by 
>> the browser. Sometimes is useful to set a more private policy, like *Origin 
>> When Cross-Origin*, to prevent disclosing sensitive URL info to a 
>> third-party, like a password reset token for example.
>>
>> But one can't just set the policy to *Origin When Cross-Origin*, because 
>> it will break on Safari, since Safari doesn't adhere to newest spec and 
>> defaults to no-referrer, which breaks form submits on HTTPS because of 
>> Django strict referrer check. Also, I can't imagine now why, but some 
>> developer might want to disable referer header altogether, and can easily 
>> do so by setting policy to *No Referrer*. See the rationale 
>>  
>> behind strict referrer check and the code 
>> 
>> .
>>
>> Maybe Django shouldn't do do strict referrer check anymore?
>> It's very strange to change a HTML meta tag and break everything. And 
>> break in staging specifically, because this happens only on secure requests.
>>
>> If Django still needs 
>>  the strict 
>> referrer check, maybe a better error message should be implemented.
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-develop...@googlegroups.com .
>> To post to this group, send email to django-d...@googlegroups.com 
>> .
>> Visit this group at http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/3dcbec32-b180-4cba-9276-731946fdccf6%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/55a87572-3459-481b-8749-9ebc562c4f66%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Possible bug transaction rollback or SQLite backend

[Jonas H]

Hi there,

there seems to be something wrong with either the SQLite backend, the 
SQLite library itself or Django's transaction handling. Whenever I try to 
run the test suite of a specific project of mine 
(https://github.com/jonashaag/fahrtkostenrechner), using 
`fahrtkostenrechner/manage.py test events`, it shows the following behavior:

* On Linux, it doesn't crash and shows actual test failures.
* On OSX, with SQLite's in-memory database as test database, a segfault (!) 
occurs. (I'm not familiar with the lower-level Python SQLite bindings, but 
I guess a segfault should *never* happen in the first place?!)
* On OSX, with a on-disk test database, a 
"django.db.utils.ProgrammingError: Cannot operate on a closed database." 
(caused by `_cursor()`: 
https://github.com/django/django/blob/4d0f8831a7498ab3b1ebcf4cafa2ee234503e4f8/django/db/backends/base/base.py#L206)
 
occurs.

It looks to me that the cause of this is some unfinished transaction 
rollback, but I'm not sure, so I'm asking for guidance here. In the file 
linked above in L193, is it legitimate for `needs_rollback` to  be True? In 
my debugging I found `connection != None` and `needs_rollback=True` 
whenever `_cursor()` fails in L206, so I figured maybe there might be an 
outstanding rollback for some reason?

I use Python 3.5, SQLite 3.9.2 and I can reproduce the crash on Django 
>=1.8.4,<1.9.

Jonas

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/39e18dc4-7e7d-4e99-a56c-e0e133ff5938%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Validation of m2m

[Aymeric Augustin]

Hello Frederico,

It appears that you're hitting the problem described in the "Avoid catching
exceptions inside atomic!" warning on this page:
https://docs.djangoproject.com/en/1.8/topics/db/transactions/#handling-exceptions-within-postgresql-transactions

To obtain that sort of result, I suppose you must be catching an
IntegrityError, re-raising a ValidationError, which Django in turn catches,
and then you hit that traceback.

Adding an atomic block inside your try/catch block that catches the
IntegrityError will resolve that particular problem — putting that part of
the discussion into django-users territory.

If this isn't what happens, please post your code and ask for help on
django-users.

-- 
Aymeric

2015-12-03 13:28 GMT+01:00 Federico Capoano :

> Hi everybody,
>
> I am sure it has happened to many of you.
>
> Validating m2m BEFORE saving the relationships is very hard and time
> consuming.
>
> Now this solution:
> http://schinckel.net/2012/02/06/pre-validating-many-to-many-fields./
>
> Proposes to solve it with a ModelForm in the admin.
> Cool, that works.
>
> But, if I want to enforce validation on the model, to avoid corrupted
> data, I notice the signal is executed in a transaction block, in which if I
> raise a ValidationError I get the following:
>
> Traceback (most recent call last):
>   File
> "/var/www/django-netjsonconfig/django_netjsonconfig/tests/test_device.py",
> line 106, in test_m2m_validation
> d.templates.add(t)
>   File
> "/home/nemesis/.virtualenvs/djnetconfig3/lib/python3.4/site-packages/django/db/models/fields/related_descriptors.py",
> line 843, in add
> self._add_items(self.source_field_name, self.target_field_name, *objs)
>   File
> "/home/nemesis/.virtualenvs/djnetconfig3/lib/python3.4/site-packages/sortedm2m/fields.py",
> line 138, in _add_items
> for val in vals:
>   File
> "/home/nemesis/.virtualenvs/djnetconfig3/lib/python3.4/site-packages/django/db/models/query.py",
> line 258, in __iter__
> self._fetch_all()
>   File
> "/home/nemesis/.virtualenvs/djnetconfig3/lib/python3.4/site-packages/django/db/models/query.py",
> line 1074, in _fetch_all
> self._result_cache = list(self.iterator())
>   File
> "/home/nemesis/.virtualenvs/djnetconfig3/lib/python3.4/site-packages/django/db/models/query.py",
> line 158, in __iter__
> for row in compiler.results_iter():
>   File
> "/home/nemesis/.virtualenvs/djnetconfig3/lib/python3.4/site-packages/django/db/models/sql/compiler.py",
> line 806, in results_iter
> results = self.execute_sql(MULTI)
>   File
> "/home/nemesis/.virtualenvs/djnetconfig3/lib/python3.4/site-packages/django/db/models/sql/compiler.py",
> line 852, in execute_sql
> cursor.execute(sql, params)
>   File
> "/home/nemesis/.virtualenvs/djnetconfig3/lib/python3.4/site-packages/django/db/backends/utils.py",
> line 59, in execute
> self.db.validate_no_broken_transaction()
>   File
> "/home/nemesis/.virtualenvs/djnetconfig3/lib/python3.4/site-packages/django/db/backends/base/base.py",
> line 429, in validate_no_broken_transaction
> "An error occurred in the current transaction. You can't "
> django.db.transaction.TransactionManagementError: An error occurred in the
> current transaction. You can't execute queries until the end of the
> 'atomic' block.
>
> This is surely an area that needs improvement in django.
>
> Why is it so hard?
>
> Best regards
> Federico
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/2e6e82d0-0645-4fd7-8905-d327c99b6352%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Aymeric.

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

Validation of m2m

[Federico Capoano]

Hi everybody,

I am sure it has happened to many of you.

Validating m2m BEFORE saving the relationships is very hard and time 
consuming.

Now this solution:
http://schinckel.net/2012/02/06/pre-validating-many-to-many-fields./

Proposes to solve it with a ModelForm in the admin.
Cool, that works.

But, if I want to enforce validation on the model, to avoid corrupted data, 
I notice the signal is executed in a transaction block, in which if I raise 
a ValidationError I get the following:

Traceback (most recent call last):
  File 
"/var/www/django-netjsonconfig/django_netjsonconfig/tests/test_device.py", 
line 106, in test_m2m_validation
d.templates.add(t)
  File 
"/home/nemesis/.virtualenvs/djnetconfig3/lib/python3.4/site-packages/django/db/models/fields/related_descriptors.py",
 
line 843, in add
self._add_items(self.source_field_name, self.target_field_name, *objs)
  File 
"/home/nemesis/.virtualenvs/djnetconfig3/lib/python3.4/site-packages/sortedm2m/fields.py",
 
line 138, in _add_items
for val in vals:
  File 
"/home/nemesis/.virtualenvs/djnetconfig3/lib/python3.4/site-packages/django/db/models/query.py",
 
line 258, in __iter__
self._fetch_all()
  File 
"/home/nemesis/.virtualenvs/djnetconfig3/lib/python3.4/site-packages/django/db/models/query.py",
 
line 1074, in _fetch_all
self._result_cache = list(self.iterator())
  File 
"/home/nemesis/.virtualenvs/djnetconfig3/lib/python3.4/site-packages/django/db/models/query.py",
 
line 158, in __iter__
for row in compiler.results_iter():
  File 
"/home/nemesis/.virtualenvs/djnetconfig3/lib/python3.4/site-packages/django/db/models/sql/compiler.py",
 
line 806, in results_iter
results = self.execute_sql(MULTI)
  File 
"/home/nemesis/.virtualenvs/djnetconfig3/lib/python3.4/site-packages/django/db/models/sql/compiler.py",
 
line 852, in execute_sql
cursor.execute(sql, params)
  File 
"/home/nemesis/.virtualenvs/djnetconfig3/lib/python3.4/site-packages/django/db/backends/utils.py",
 
line 59, in execute
self.db.validate_no_broken_transaction()
  File 
"/home/nemesis/.virtualenvs/djnetconfig3/lib/python3.4/site-packages/django/db/backends/base/base.py",
 
line 429, in validate_no_broken_transaction
"An error occurred in the current transaction. You can't "
django.db.transaction.TransactionManagementError: An error occurred in the 
current transaction. You can't execute queries until the end of the 
'atomic' block.

This is surely an area that needs improvement in django.

Why is it so hard?

Best regards
Federico

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/2e6e82d0-0645-4fd7-8905-d327c99b6352%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Feedback about FormMixin get_context_data()

[Wayne Merry]

Hi all,

Going through the process of scoping upgrading from 1.8 to 1.9 and after 
having hundreds of test cases failing with "TypeError: get_context_data() 
missing 1 required positional argument: 'form'" I would just like to make 
an observation.

It seems like it is a good optimization - as discussed in 
https://code.djangoproject.com/ticket/24643 to move form init from 
get()/post() to it's own get_context_data() method for consistency. However 
this change was not made with any depreciation schedule. The release notes 
discuss that it may be backward incompatible if methods don't call super(), 
but it is also incompatible if user derived get_context_data() methods are 
written presuming that the form has already been instantiated and has 
form=form as a keyword argument. I'll need to work out the best way of 
dealing with this, but it would appear that I am going to have to go from 
1.8 to 1.9 hard without being able to have code pass tests in both at the 
same time - unless I introspect the Django version. It would have been 
better if this change had have gone through a deprecation cycle.

Cheers,
Wayne Merry


-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/f436dd35-f2e9-4e38-83e8-35c9c0e122f3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: is_authenticated as property

[Aymeric Augustin]

2015-12-03 7:02 GMT+01:00 Josh Smeaton :

> I think we should be asking.. why not? If there's not a good reason not
> to, let's make it a callable and a property.
>

The original discussion dates back to 2008; back then I believe we were
slightly more resistant to change, especially when it came to complicating
things to increase user-friendliness ;-)

-- 
Aymeric.

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