Re: [Django] #21113: django_admin_log table stores messages in different languages depending on which language was active while editing.

[Django]

#21113: django_admin_log table stores messages in different languages depending 
on
which language was active while editing.
-+
 Reporter:  dimyur27@…   |Owner:
 Type:  New feature  |   Status:  new
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  admin logs i18n  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+
Changes (by jooyous):

 * status:  assigned => new
 * needs_better_patch:  0 => 1
 * has_patch:  0 => 1
 * needs_tests:  0 => 1
 * owner:  jooyous =>


Comment:

 https://github.com/django/django/pull/3345

 Here's a partial fix for this bug. It changes the log messages so that
 they're saved in the database in English and then parsed and translated
 when they need to be displayed. However, due to the way the change
 messages were written upon being entered into the database, I wasn't able
 to properly distinguish between different types of save messages. For
 example, if an object (for example, a Poll or Choice) contained a period
 or quotation marks in the body, I could not tell the difference between
 the end of the message and the punctuation within the message body. So I'm
 only submitting a partial fix. From what I could test, it works pretty
 well for Users. I was also having some trouble getting certain words to
 translate.

 If having history messages displayed in different languages is a priority,
 I would recommend restructuring the logging functionality entirely, and
 have the messages be saved in an unambiguously delimited format (yaml?
 json? something!) so that they can be formed into translatable sentences
 after they are extracted from the database. I would be willing to work on
 this if an issue gets made!

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

Re: [Django] #23626: Change coding style for sql, params return lines

[Django]

#23626: Change coding style for sql, params return lines
-+-
 Reporter:  mjtamlyn |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  1|
-+-

Comment (by AmiZya):

 @mjtamlyn should I create a new ticket for the formatting part in the ORM
 ?

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

Re: [Django] #23626: Change coding style for sql, params return lines

[Django]

#23626: Change coding style for sql, params return lines
-+-
 Reporter:  mjtamlyn |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  1|
-+-

Comment (by mjtamlyn):

 This ticket was opened two days ago and there are no commits along those
 lines I can see. For example I mean places like:
 
https://github.com/django/django/blob/bc46e4d4fa61eead13fe58048ae646f07d632e4f/django/db/models/lookups.py#L149-L154
 
https://github.com/django/django/blob/92a17eaae081a213171b044858d6fc29df2df733/django/contrib/postgres/fields/array.py#L167-L172

 There aren't that many, and several are clearer to read than the examples
 in that PR. The docs however suggest the current style used. It may be
 worth looking more generally at string manipulation in the ORM and using
 `.format()` instead of `%s` notation.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

Re: [Django] #23626: Change coding style for sql, params return lines

[Django]

#23626: Change coding style for sql, params return lines
-+-
 Reporter:  mjtamlyn |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  1|
-+-

Comment (by jpadilla):

 This seems to be already taken care of, pretty sure it can be closed.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

Re: [Django] #11313: list_editable fields don't support 'save' in multiuser environment

[Django]

#11313: list_editable fields don't support 'save' in multiuser environment
+
 Reporter:  margieroginski  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  contrib.admin   |  Version:  1.1-beta
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  1
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+

Comment (by patjlm):

 This issue persists un Django 1.6.7. If an admin opens a page with
 list_editable items while data can be inserted (from admin or other flow),
 field values may end up being updated with values from other instances of
 the model.
 This created a big mess for us recently: around 50 records got updated
 with wrong values.
 Is there any timeline for a fix? Does anyone know what should be patched?
 Thanks,
 Patrick

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

Re: [Django] #23448: Update ISO_INPUT_FORMATS to allow date filtering for ISO8601 dates

[Django]

#23448: Update ISO_INPUT_FORMATS to allow date filtering for ISO8601 dates
-+-
 Reporter:  jaegerpicker |Owner:  jpadilla
 Type:  New feature  |   Status:  assigned
Component:  Utilities|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  datetime,| Triage Stage:  Accepted
  isoformat, ISO8601 |  Needs documentation:  1
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by jpadilla):

 Replying to [comment:6 jaegerpicker]:

 Since this was originally an issue you were working on, and apparently
 needs a bit more work after my PR, which I don't fully understand, would
 you want to pick this up again or should we just close it for now?

 > Sorry, I got swallowed by work and family commitments and wasn't able to
 come back and update the PR based upon feedback. Thanks @jpadilla for
 updating this.
 >
 > ISO_INPUT_FORMATS isn't referenced directly in either django-filter nor
 django-rest-framework. The chain goes like this:
 > - DRF references DF.filterset (line 191 in my local django-filter)
 >  - DF.filter.DateTimeFilter which references
 django.forms.fields.DateTimeFleld (on line 120 in filters.py in django-
 filters) which calls
 > - django.formats.get_format_lazy('DATETIME_INPUT_FORMATS') which
 returns a list of all the setup datetime formats to try and parse the
 incoming string against using strptime
 >- This is on line 490 in the django.forms.fields.py file.
 get_format_lazy calls get_format which references ISO_INPUT_FORMATS.
 >
 > That's why updating the ISO_INPUT_FORMATS dict fixes the DRF issue for
 most/some cases. I had overlooked the timezone issue with ISO8601
 apparently.  Maybe we should also update the BaseTemporalField
 (DateTimeFields super class) to use the django.utils.dateparse instead of
 strptime?
 >
 > That seems like a larger change than the original but seems like the
 correct answer to me.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

Re: [Django] #23579: Default Geometry representation from WKT to EWKT

[Django]

#23579: Default Geometry representation from WKT to EWKT
-+--
 Reporter:  claudep  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  GIS  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Description changed by claudep:

Old description:

> Currently, the default `__str__` representation of a `GEOSGeometry`
> object is its WKT representation (e.g. `"POINT (1 2)"`).
> I'd like to suggest moving to the EWKT representation which includes the
> SRID information (e.g. `"SRID=4326;POINT (1 2)"`).
> For me, coordinates without SRID is like an encoded string without
> knowing its encoding, or a datetime object without the timezone.
>
> The change is trivial. There is a small backwards compatibility issue,
> essentially for people testing the output of `str(geom)`, and it also
> means that the SRID will also appear in `loaddata` output, which is
> welcome in my opinion.
>
> Comments welcome.

New description:

 Currently, the default `__str__` representation of a `GEOSGeometry` object
 is its WKT representation (e.g. `"POINT (1 2)"`).
 I'd like to suggest moving to the EWKT representation which includes the
 SRID information (e.g. `"SRID=4326;POINT (1 2)"`).
 For me, coordinates without SRID is like an encoded string without knowing
 its encoding, or a datetime object without the timezone.

 The change is trivial. There is a small backwards compatibility issue,
 essentially for people testing the output of `str(geom)`, and it also
 means that the SRID will also appear in `dumpdata` output, which is
 welcome in my opinion.

 Comments welcome.

--

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

Re: [Django] #23579: Default Geometry representation from WKT to EWKT

[Django]

#23579: Default Geometry representation from WKT to EWKT
-+--
 Reporter:  claudep  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  GIS  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by claudep):

 * has_patch:  0 => 1


Comment:

 https://github.com/django/django/pull/3344

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

Re: [Django] #23641: Apps.set_installed_apps causes signals registered with apps as senders not to be received

[Django]

#23641: Apps.set_installed_apps causes signals registered with apps as senders 
not
to be received
--+
 Reporter:  wrwrwr|Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by aaugustin):

 * needs_better_patch:   => 0
 * needs_docs:   => 0
 * needs_tests:   => 0
 * stage:  Unreviewed => Accepted


Comment:

 `set_installed_apps` is a private API required mainly to test Django
 itself and I don't think we can make it work reliably in general.

 That said, moving signal registration code to AppConfig.ready() looks like
 a better design in general. Accepting the ticket on this basis.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

Re: [Django] #23468: fixtures are imported twice with duplicate FIXTURE_DIRS

[Django]

#23468: fixtures are imported twice with duplicate FIXTURE_DIRS
-+-
 Reporter:  karyon   |Owner:  kswiat
 Type:  Bug  |   Status:  assigned
Component:  Core (Management |  Version:  1.6
  commands)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by kswiat):

 * needs_better_patch:  1 => 0
 * needs_tests:  1 => 0


Comment:

 Pull request ready.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

Re: [Django] #23546: callproc **kwargs or *args parameter

[Django]

#23546: callproc **kwargs or *args parameter
-+-
 Reporter:  fatal10110   |Owner:
 Type:  New feature  |  averybigant
Component:  Database layer   |   Status:  assigned
  (models, ORM)  |  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:  oracle   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by averybigant):

 * has_patch:  0 => 1


Comment:

 pull request created
 https://github.com/django/django/pull/3342
 already tested on ubuntu 12.04 server(amd64) with oracle XE 11g

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

[Django] #23642: LocMemCache.incr is not thread safe

[Django]

#23642: LocMemCache.incr is not thread safe
-+
 Reporter:  tchaumeny|  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  Core (Cache system)  |Version:  master
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 `LocMemCache` is documented as being thread-safe, but its `incr` operation
 isn't: there is not lock wrapping the whole get+set operation.

 The code below demonstrates the issue:

 {{{
 import threading

 from django.core.cache.backends.locmem import LocMemCache

 cache = LocMemCache('test', {})

 cache.set('foo', 0)

 def increment(key):
 cache.incr(key)

 threads = []
 for i in range(20):
 t = threading.Thread(target=increment, args=('foo',))
 t.start()
 threads.append(t)

 for t in threads:
 t.join()

 print cache.get('foo')   # Random results — 20 is expected
 }}}

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

[Django] #23641: Apps.set_installed_apps causes signals registered with apps as senders not to be received

[Django]

#23641: Apps.set_installed_apps causes signals registered with apps as senders 
not
to be received
--+
 Reporter:  wrwrwr|  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Core (Other)  |Version:  master
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 Calling `Apps.set_installed_apps` before `DiscoverRunner.setup_databases`
 causes pre/post_migrate signal handlers registered on module import with
 app configs as senders not to be executed for the test database.

 The signal dispatcher stores `id()` of the  sender argument provided to
 `connect` to identify the sender that we're interested in receiving the
 signals from, in case of `post_migrate` signals this is often an id of an
 `AppConfig` for the registering app. When `set_installed_apps` is called
 it reinstantiates all app configs. If afterwards you send a signal using
 app config from the global app registry as the sender (as is the case in
 `emit_post_migrate_signal` when setting up test databases), its id won't
 match the one stored by the dispatcher, thus signal handlers won't get
 executed.

 [https://github.com/wrwrwr/django/tree/fix/missing-default-site-with-set-
 installed-apps A branch] with an example test case and a possible partial
 fix (that in full would be moving all module-level signal registration to
 `AppConfig.ready`).

 [https://github.com/wrwrwr/mezzanine/blob/maintenance/1.8-discover-test-
 runner/mezzanine/utils/tests.py#L117 A sketch] of a possible more general
 solution / workaround (this Mezzanine wrapper for `DiscoverRunner` turned
 out pretty involved, you're welcome to suggest a cleaner implementation
 :-)

 See also #22688: AppConfig.ready is going to get called for every
 instance, so should be a good place to put these signal registrations.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

Re: [Django] #23300: TestCase.assertTemplateUsed passes erroneously on an HttpResponse

[Django]

#23300: TestCase.assertTemplateUsed passes erroneously on an HttpResponse
-+-
 Reporter:  zags |Owner:  davide-
 Type:  Bug  |  ceretti
Component:  Testing framework|   Status:  assigned
 Severity:  Normal   |  Version:  master
 Keywords:  asserttemplateused   |   Resolution:
  template   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by davide-ceretti):

 * owner:  nobody => davide-ceretti
 * status:  new => assigned
 * version:  1.6 => master


--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

Re: [Django] #23624: Regression in ManyToManyField with through, runtime-generated models

[Django]

#23624: Regression in ManyToManyField with through, runtime-generated models
-+-
 Reporter:  ludoo|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by aaugustin):

 When you suspect a regression caused by the app-loading refactor, I
 recommend running under -Wall or -Werror.

 Django sends warnings in cases that will become errors to make the
 transition slightly smoother. Unfortunately, since
 PendingDeprecationWarnings are silent by default, this makes it a bit
 difficult to pinpoint the root cause ofo some errors.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

Re: [Django] #23640: StaticLiveServerTestCase does not properly respect data migrations

[Django]

#23640: StaticLiveServerTestCase does not properly respect data migrations
-+-
 Reporter:  eldamir  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Testing framework|  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:  data migration,  | Triage Stage:
  functional tests   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by eldamir):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


Old description:

> When data migrations exists for a project, it is expected that each test
> case has these migrations run before running the test.
> That is indeed the case for django.tests.TestCase (unit tests), but it is
> NOT working for
> django.contrib.staticfiles.testing.StaticLiveServerTestCase (functional
> tests).
>
> Migrations seem to be run for each class, e.g.
> MyTestCase(StaticLiveServerTestCase), but not for the methods of this
> class. That is, if MyTestCase has 3 methods with tests, the migrations
> are only loaded for the first one, and then the database is wiped, and
> the objects from the data migration is no longer present for the next two
> methods.
>
> A minimal reproduction of this issue - along with a guide to the issue
> and which files to look at - can be found here:
> https://github.com/eldamir/django_migration_bug

New description:

 When data migrations exist for a project, it is expected that each test
 case has these migrations run before running the test.
 That is indeed the case for django.tests.TestCase (unit tests), but it is
 NOT working for
 django.contrib.staticfiles.testing.StaticLiveServerTestCase (functional
 tests).

 Migrations seem to be run for each class, e.g.
 MyTestCase(StaticLiveServerTestCase), but not for the methods of this
 class. That is, if MyTestCase has 3 methods with tests, the migrations are
 only loaded for the first one, and then the database is wiped, and the
 objects from the data migration are no longer present for the next two
 methods.

 A minimal reproduction of this issue - along with a guide to the issue and
 which files to look at - can be found here:
 https://github.com/eldamir/django_migration_bug

--

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

[Django] #23640: StaticLiveServerTestCase does not properly respect data migrations

[Django]

#23640: StaticLiveServerTestCase does not properly respect data migrations
+--
 Reporter:  eldamir |  Owner:  nobody
 Type:  Bug | Status:  new
Component:  Testing |Version:  1.7
  framework |   Keywords:  data migration, functional tests
 Severity:  Normal  |  Has patch:  0
 Triage Stage:  Unreviewed  |  UI/UX:  0
Easy pickings:  0   |
+--
 When data migrations exists for a project, it is expected that each test
 case has these migrations run before running the test.
 That is indeed the case for django.tests.TestCase (unit tests), but it is
 NOT working for
 django.contrib.staticfiles.testing.StaticLiveServerTestCase (functional
 tests).

 Migrations seem to be run for each class, e.g.
 MyTestCase(StaticLiveServerTestCase), but not for the methods of this
 class. That is, if MyTestCase has 3 methods with tests, the migrations are
 only loaded for the first one, and then the database is wiped, and the
 objects from the data migration is no longer present for the next two
 methods.

 A minimal reproduction of this issue - along with a guide to the issue and
 which files to look at - can be found here:
 https://github.com/eldamir/django_migration_bug

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

Re: [Django] #23618: Migrations only work for apps containing models

[Django]

#23618: Migrations only work for apps containing models
-+-
 Reporter:  seddonym |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.7
Component:  Migrations   |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by claudep):

 I've update https://github.com/django/django/pull/3340.
 At least the test suite now starts, but strangely, the test suite passes
 when I only run it with `django.contrib.gis` test label, but fails with no
 test labels.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

Re: [Django] #22258: Show progress during dumpdata and loaddata

[Django]

#22258: Show progress during dumpdata and loaddata
-+-
 Reporter:  Gwildor  |Owner:  mrfuxi
 Type:  New feature  |   Status:  assigned
Component:  Core (Management |  Version:  master
  commands)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by mrfuxi):

 * owner:  nobody => mrfuxi
 * status:  new => assigned


Comment:

 I was thinking of adding some kind of utility to allow showing progress
 from any management command.

 As far as I looked (loading data) there is no clean way of showing % of
 progress because of generators/reading streams from files, so progress
 like during tests. For data load it might be possible to show proper
 progress bar.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

Re: [Django] #23063: send email 1.6.5 OK, 1.7c1 malformed packet in wireshark

[Django]

#23063: send email 1.6.5 OK, 1.7c1 malformed packet in wireshark
-+-
 Reporter:  contact@…|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Mail)  |  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:  send_mail, smtp, | Triage Stage:  Accepted
  malformed, packet  |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by apollo13):

 I updated the PR with a test, but it is a bit ugly -- the whole smtplib
 module is a bit annoying ;)

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

Re: [Django] #23628: AlterModelOptions should check for changes

[Django]

#23628: AlterModelOptions should check for changes
+--
 Reporter:  Naddiseo|Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  1.7
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Changes (by bmispelon):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 Hi,

 This actually depends on your Python version.
 On Python 3.3 and later, the order of dictionaries will change between
 different runs (that feature is called "hash randomization" if you want to
 look deeper).

 On earlier versions of Python though, that order is consistent so the
 autodetector doesn't see any changes and no new migrations are created.

 I'm not sure if this warrants the additional code complexity.
 If you need a consistent order here you could use an `OrderedDict` or user
 `permissions = sorted(PERM_DEFS.keys())`.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

Re: [Django] #23624: Regression in ManyToManyField with through, runtime-generated models

[Django]

#23624: Regression in ManyToManyField with through, runtime-generated models
-+-
 Reporter:  ludoo|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by bmispelon):

 I've bisected the error to this commit:
 9f13c3328199d2fa70235cdc63bb06b1efc5b117

 Note that using Python3, you get a slightly more useful error message:
 {{{
 Traceback (most recent call last):
   File "./django/db/models/fields/related.py", line 876, in get_queryset
 return
 self.instance._prefetched_objects_cache[self.prefetch_cache_name]
 AttributeError: 'A' object has no attribute '_prefetched_objects_cache'

 During handling of the above exception, another exception occurred:

 Traceback (most recent call last):
   File "t.py", line 20, in 
 a.b_s.all() # works in 1.6, raises FieldError in 1.7
   File "./django/db/models/manager.py", line 191, in all
 return self.get_queryset()
   File "./django/db/models/fields/related.py", line 882, in get_queryset
 return qs._next_is_sticky().filter(**self.core_filters)
   File "./django/db/models/query.py", line 691, in filter
 return self._filter_or_exclude(False, *args, **kwargs)
   File "./django/db/models/query.py", line 709, in _filter_or_exclude
 clone.query.add_q(Q(*args, **kwargs))
   File "./django/db/models/sql/query.py", line 1287, in add_q
 clause, require_inner = self._add_q(where_part, self.used_aliases)
   File "./django/db/models/sql/query.py", line 1314, in _add_q
 current_negated=current_negated, connector=connector)
   File "./django/db/models/sql/query.py", line 1138, in build_filter
 lookups, parts, reffed_aggregate = self.solve_lookup_type(arg)
   File "./django/db/models/sql/query.py", line 1076, in solve_lookup_type
 _, field, _, lookup_parts = self.names_to_path(lookup_splitted,
 self.get_meta())
   File "./django/db/models/sql/query.py", line 1383, in names_to_path
 self.raise_field_error(opts, name)
   File "./django/db/models/sql/query.py", line 1389, in raise_field_error
 "Choices are: %s" % (name, ", ".join(available)))
 django.core.exceptions.FieldError: Cannot resolve keyword 'a' into field.
 Choices are: a_s, id, name
 }}}

 (another interesting thing is that while bisecting, I encountered a
 different error and even a RecursionError).

 Still not sure if this is a bug in Django or if your use-case is just not
 supported. It certainly looks weird.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

Re: [Django] #23618: Migrations only work for apps containing models

[Django]

#23618: Migrations only work for apps containing models
-+-
 Reporter:  seddonym |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.7
Component:  Migrations   |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by claudep):

 Typical GIS error (whatever the backend) when removing the
 `app_config.models_module` check:
 {{{
 Applying gis_migrations.0001_initial...Traceback (most recent call last):
   File "./runtests.py", line 391, in 
 options.failfast, options.modules)
   File "./runtests.py", line 234, in django_tests
 test_labels or get_installed(), extra_tests=extra_tests)
   File "/home/jenkins/workspace/django-pull-
 requests/database/mysql_gis/python/python2.7/django/test/runner.py", line
 151, in run_tests
 old_config = self.setup_databases()
   File "/home/jenkins/workspace/django-pull-
 requests/database/mysql_gis/python/python2.7/django/test/runner.py", line
 113, in setup_databases
 return setup_databases(self.verbosity, self.interactive, self.keepdb,
 **kwargs)
   File "/home/jenkins/workspace/django-pull-
 requests/database/mysql_gis/python/python2.7/django/test/runner.py", line
 304, in setup_databases
 serialize=connection.settings_dict.get("TEST", {}).get("SERIALIZE",
 True),
   File "/home/jenkins/workspace/django-pull-
 requests/database/mysql_gis/python/python2.7/django/db/backends/creation.py",
 line 385, in create_test_db
 test_flush=True,
   File "/home/jenkins/workspace/django-pull-
 
requests/database/mysql_gis/python/python2.7/django/core/management/__init__.py",
 line 118, in call_command
 return command.execute(*args, **defaults)
   File "/home/jenkins/workspace/django-pull-
 requests/database/mysql_gis/python/python2.7/django/core/management/base.py",
 line 419, in execute
 output = self.handle(*args, **options)
   File "/home/jenkins/workspace/django-pull-
 
requests/database/mysql_gis/python/python2.7/django/core/management/commands/migrate.py",
 line 193, in handle
 executor.migrate(targets, plan, fake=options.get("fake", False))
   File "/home/jenkins/workspace/django-pull-
 requests/database/mysql_gis/python/python2.7/django/db/migrations/executor.py",
 line 63, in migrate
 self.apply_migration(migration, fake=fake)
   File "/home/jenkins/workspace/django-pull-
 requests/database/mysql_gis/python/python2.7/django/db/migrations/executor.py",
 line 91, in apply_migration
 if self.detect_soft_applied(migration):
   File "/home/jenkins/workspace/django-pull-
 requests/database/mysql_gis/python/python2.7/django/db/migrations/executor.py",
 line 135, in detect_soft_applied
 apps = project_state.render()
   File "/home/jenkins/workspace/django-pull-
 requests/database/mysql_gis/python/python2.7/django/db/migrations/state.py",
 line 89, in render
 model=lookup_model,
 ValueError: Lookup failed for model referenced by field
 gis_migrations.Household.neighborhood: gis.Neighborhood
 }}}
 http://djangoci.com/job/django-pull-requests/1249/

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

Re: [Django] #19716: Support microsecond precision in MySQL ORM DateTimeField

[Django]

#19716: Support microsecond precision in MySQL ORM DateTimeField
-+-
 Reporter:  erik@…   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by claudep):

 * needs_better_patch:  1 => 0


Comment:

 Patch updated.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

Re: [Django] #23630: AlterModelTable doesn't rename auto-created tables

[Django]

#23630: AlterModelTable doesn't rename auto-created tables
+
 Reporter:  Naddiseo|Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  1.7
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Accepted
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+
Changes (by shaib):

 * cc: shaib (added)


Comment:

 comment:1 : The error seems to be about table `asdf`, the named table of
 the model. Are you sure you ran the migration?

 Also, according to https://docs.djangoproject.com/en/dev/ref/models/fields
 /#ref-manytomany changing the table name for model Foo should not change
 anything; the M2M table should still be named `app_bar_foos`. A change
 should happen if the `Bar` table name is modified.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

Re: [Django] #23639: Doc error in RegexValidator.regex

[Django]

#23639: Doc error in RegexValidator.regex
---+
 Reporter:  claudep|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Documentation  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+

Comment (by claudep):

 Suggested patch:
 {{{
 #!diff
 diff --git a/docs/ref/validators.txt b/docs/ref/validators.txt
 index 260c066..0b66dd2 100644
 --- a/docs/ref/validators.txt
 +++ b/docs/ref/validators.txt
 @@ -81,11 +81,13 @@ to, or in lieu of custom ``field.clean()`` methods.
  .. attribute:: regex

  The regular expression pattern to search for the provided
 ``value``,
 -or a pre-compiled regular expression. Raises a
 +or a pre-compiled regular expression. By default, raises a
  :exc:`~django.core.exceptions.ValidationError` with
 :attr:`message`
 -and :attr:`code` if :attr:`inverse_match` is ``False`` and a
 match is
 -found, or if :attr:`inverse_match` is ``True`` and a match is not
 found.
 -By default, matches any string (including an empty string).
 +and :attr:`code` if a match is not found. That standard behavior
 might
 +be reversed by setting :attr:`inverse_match` to ``True``, meaning
 that
 +the :exc:`~django.core.exceptions.ValidationError` is raised when
 a
 +match **is** found. By default, matches any string (including an
 empty
 +string).

  .. attribute:: message
 }}}

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

Re: [Django] #23639: Doc error in RegexValidator.regex

[Django]

#23639: Doc error in RegexValidator.regex
---+
 Reporter:  claudep|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Documentation  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+
Changes (by bmispelon):

 * easy:  0 => 1
 * stage:  Unreviewed => Accepted


Comment:

 Hi,

 You're right (and I also find this sentence really hard to parse, but
 maybe that's just me):

 {{{#!python
 >>> RegexValidator(regex='[a-z]')('1')
 Traceback (most recent call last):
   File "", line 1, in 
   File "/home/tisba/Programming/testbed/boogz/django/core/validators.py",
 line 51, in __call__
 raise ValidationError(self.message, code=self.code)
 django.core.exceptions.ValidationError: ['Enter a valid value.']
 >>> RegexValidator(regex='[a-z]', inverse_match=True)('1')

 }}}

 I wouldn't be opposed to a rewrite of this paragraph since I find it quite
 confusing.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

[Django] #23639: Doc error in RegexValidator.regex

[Django]

#23639: Doc error in RegexValidator.regex
-+
   Reporter:  claudep|  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Documentation  |Version:  master
   Severity:  Normal |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 In
 
https://docs.djangoproject.com/fr/1.7/ref/validators/#django.core.validators.RegexValidator.regex,
 I think that the effects of `inverse_match` are reversed. A
 `ValidationError` is raised when `inverse_match=True` and a match **is**
 found. Can someone confirm? Boolean logic, we love you!

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

Re: [Django] #23637: Remove TUX from static-files and modwsgi docs

[Django]

#23637: Remove TUX from static-files and modwsgi docs
--+
 Reporter:  collinanderson|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by claudep):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * version:  1.7 => master
 * needs_docs:   => 0
 * type:  Uncategorized => Cleanup/optimization
 * stage:  Unreviewed => Accepted


Comment:

 Sure, mentioning Apache and nginx seems sufficient.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

Re: [Django] #23449: Saving models with unsaved ForeignKey

[Django]

#23449: Saving models with unsaved ForeignKey
-+-
 Reporter:  pjrobertson  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Release blocker  | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by pjrobertson):

 @coder9042 - you're right about the `bulk_create` reference. I hadn't
 quite thought that through, and the example I gave wasn't great.

 So if we assume that this change *is* right, and that what I'm suggesting
 *isn't* right, what would be the suggested method for trying to achieve
 what I want? This change is forwards incompatible, and I cannot see any
 way of migrating code to work with this change, other than forcing
 potentially 100s of 'wasted' objects to be stored in the database, *just*
 to meet a Django validation.

 Again, to reiterate incase you can come up with any forwards compatible
 solution, here's my scenario (fleshed out a bit more):

 {{{
 mods = []
 for xml_element in xml.findall('item'):
  a = ModelA(name=xml_element.findtext('name')) # and other things
  b = ModelB(name='me', a=a)
  mods.append(b)

 values_to_save = [c for c in mods if
 b.conditional_test_based_on_a_and_b()]

 # save the values_to_save, discard the rest
 }}}

 Currently the only forwards compatible solution I see is to create another
 object class that mirrors my ModelB class, do all the logic with that,
 then 'convert' it to a ModelB object and save it if required. Not very DRY

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

Re: [Django] #23620: Use more specify assertions than assertTrue in tests

[Django]

#23620: Use more specify assertions than assertTrue in tests
-+-
 Reporter:  timgraham|Owner:
 Type:   |  averybigant
  Cleanup/optimization   |   Status:  assigned
Component:  Uncategorized|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by averybigant):

 * owner:  nobody => averybigant
 * status:  new => assigned


--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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