date:20190612

Re: [Django] #30512: Update mail backend to use modern standard library parsing approach.

2019-06-12 Thread Django

#30512: Update mail backend to use modern standard library parsing approach.
-+-
 Reporter:  Joachim Jablon   |Owner:  Joachim
 Type:   |  Jablon
  Cleanup/optimization   |   Status:  assigned
Component:  Core (Mail)  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * needs_tests:  1 => 0


-- 
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.ad46574475f175f38f4411547fe6117e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30564: Cannot create custom field that returns a queryset AND uses pre_save(). (was: Cannot create custom field that returns a queryset AND uses pre_save())

2019-06-12 Thread Django

#30564: Cannot create custom field that returns a queryset AND uses pre_save().
-+-
 Reporter:  Dan J Strohl |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 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 felixxm):

 * status:  new => closed
 * version:  2.2 => master
 * resolution:   => invalid


Comment:

 Thanks for the report, however it is not an issue in Django. It seems that
 you want to get help with your custom implementation.

 If you're on PostgreSQL you can use
 [https://docs.djangoproject.com/en/2.2/ref/contrib/postgres/fields/#arrayfield
 ArrayField] without implementing a custom field. If you're on a different
 database and you need to implement a custom field for that, then please
 use one of
 [https://code.djangoproject.com/wiki/TicketClosingReasons/UseSupportChannels
 support channels].

 `if hasattr(value, 'resolve_expression')` is the way that we prefer to
 check if something is an expression, it is used in many places.


 Closing per TicketClosingReasons/UseSupportChannels.

-- 
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.a95e4555d5060c92989336cd3b6c4d11%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30355: Specifying custom manager doesn't work with prefetch

2019-06-12 Thread Django

#30355: Specifying custom manager doesn't work with prefetch
---+
 Reporter:  Kyle Mulka |Owner:  (none)
 Type:  Bug|   Status:  new
Component:  Documentation  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  1
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by Simon Charette):

 * needs_docs:  0 => 1
 * component:  Database layer (models, ORM) => Documentation


Comment:

 I agree that it's more of a documentation issue as `prefetch_related` will
 use the default manager just like accessing a related manager does.

 In other words `Business.objects.prefetch_related('review_set')` will use
 the default manager just like `business.review_set.all()` does.

-- 
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.910c0a292fe935f8e78105782079835f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29043: test --keepdb says "Using existing test database" even if it's run for the first time

2019-06-12 Thread Django

#29043: test --keepdb says "Using existing test database" even if it's run for 
the
first time
-+-
 Reporter:  karyon   |Owner:  Hasan
 Type:   |  Ramezani
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Hasan Ramezani):

 * needs_tests:  1 => 0


Comment:

 Tests added

-- 
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.0c998aff1402bcaeb5f1943b6cedeaad%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30564: Cannot create custom field that returns a queryset AND uses pre_save()

2019-06-12 Thread Django

#30564: Cannot create custom field that returns a queryset AND uses pre_save()
-+-
 Reporter:  Dan J Strohl |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 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
-+-

Comment (by Dan J Strohl):

 Perhaps instead of using "hasattr(value, 'resolve_expression')", a
 "issubclass(value, ):" could be used?

-- 
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.08cee34c991ef21f9de7877294a4132e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30563: Optimize django.forms.widgets.Media.add.

2019-06-12 Thread Django

#30563: Optimize django.forms.widgets.Media.__add__.
--+
 Reporter:  didorothy |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Forms |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  media | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Matthias Kestenholz):

 I wonder how many distinct lists of assets you have? In the example above
 you're merging the same list 100'000 times.

 When calling `merge` earlier than at the end it will always be
 (relatively) easy to construct a failing test case.

 Maybe deduplicating the list of assets to merge would help? Something like
 (completely untested)

 {{{
 ~/Projects/django$ git diff
 diff --git a/django/forms/widgets.py b/django/forms/widgets.py
 index c8ec3c35d5..248c29b4c1 100644
 --- a/django/forms/widgets.py
 +++ b/django/forms/widgets.py
 @@ -124,7 +124,7 @@ class Media:
  """
  dependency_graph = defaultdict(set)
  all_items = OrderedSet()
 -for list_ in filter(None, lists):
 +for list_ in OrderedSet(filter(None, lists)):
  head = list_[0]
  # The first items depend on nothing but have to be part of
 the
  # dependency graph to be included in the result.
 ~/Projects/django$
 }}}

 It might be better for the memory usage to deduplicate earlier (inside
 `Media.__add__` maybe).

-- 
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.860b693d7da2d272bb998e282173318a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #30564: Cannot create custom field that returns a queryset AND uses pre_save()

2019-06-12 Thread Django

#30564: Cannot create custom field that returns a queryset AND uses pre_save()
-+-
   Reporter:  Dan J  |  Owner:  nobody
  Strohl |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  2.2
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 I tried creating a custom field that would store a string that was a list
 of pks, then return that as a queryset. (yes, I could probably have done
 it using a many2many field, but I was (am) trying to reduce the number of
 db queries for this.

 In any case, all seems to work OK until I implemented a def pre_save(self,
 model_instance, add) method on my custom field.

 What seems to be happening is that when the queryset comes back from the
 pre-save, it is run through the SQLInsertCompiler.prepare_value, which
 checks the value to see if it has a "resolve_expression" attrubute, which
 it assumes is then a SQL expression and then tries checking for
 "contains_column_references"... The QuerySet object DOES have the
 "resolve_expression" attribute, but does NOT have the others that are in
 the SQL expression objects.

 I suspect this doesn't come up much.

 My trace back

 Error
 Traceback (most recent call last):

 {{{
   File
 
"C:\Users\strohl\Documents\Project\Who\who_db\who_db_tests\test_model_methods.py",
 line 101, in setUp
 self.M1 = MixinTest.objects.create(name='M1')
   File "C:\Users\strohl\Documents\VirtualEnv\Who\lib\site-
 packages\django\db\models\manager.py", line 82, in manager_method
 return getattr(self.get_queryset(), name)(*args, **kwargs)
   File "C:\Users\strohl\Documents\VirtualEnv\Who\lib\site-
 packages\django\db\models\query.py", line 422, in create
 obj.save(force_insert=True, using=self.db)
   File "C:\Users\strohl\Documents\Project\Who\who_db\models.py", line 132,
 in save
 super(MixinTest, self).save(*args, **kwargs)
   File "C:\Users\strohl\Documents\VirtualEnv\Who\lib\site-
 packages\django\db\models\base.py", line 741, in save
 force_update=force_update, update_fields=update_fields)
   File "C:\Users\strohl\Documents\VirtualEnv\Who\lib\site-
 packages\django\db\models\base.py", line 779, in save_base
 force_update, using, update_fields,
   File "C:\Users\strohl\Documents\VirtualEnv\Who\lib\site-
 packages\django\db\models\base.py", line 870, in _save_table
 result = self._do_insert(cls._base_manager, using, fields, update_pk,
 raw)
   File "C:\Users\strohl\Documents\VirtualEnv\Who\lib\site-
 packages\django\db\models\base.py", line 908, in _do_insert
 using=using, raw=raw)
   File "C:\Users\strohl\Documents\VirtualEnv\Who\lib\site-
 packages\django\db\models\manager.py", line 82, in manager_method
 return getattr(self.get_queryset(), name)(*args, **kwargs)
   File "C:\Users\strohl\Documents\VirtualEnv\Who\lib\site-
 packages\django\db\models\query.py", line 1186, in _insert
 return query.get_compiler(using=using).execute_sql(return_id)
   File "C:\Users\strohl\Documents\VirtualEnv\Who\lib\site-
 packages\django\db\models\sql\compiler.py", line 1331, in execute_sql
 for sql, params in self.as_sql():
   File "C:\Users\strohl\Documents\VirtualEnv\Who\lib\site-
 packages\django\db\models\sql\compiler.py", line 1275, in as_sql
 for obj in self.query.objs
   File "C:\Users\strohl\Documents\VirtualEnv\Who\lib\site-
 packages\django\db\models\sql\compiler.py", line 1275, in 
 for obj in self.query.objs
   File "C:\Users\strohl\Documents\VirtualEnv\Who\lib\site-
 packages\django\db\models\sql\compiler.py", line 1274, in 
 [self.prepare_value(field, self.pre_save_val(field, obj)) for field in
 fields]
   File "C:\Users\strohl\Documents\VirtualEnv\Who\lib\site-
 packages\django\db\models\sql\compiler.py", line 1205, in prepare_value
 if value.contains_column_references:
 AttributeError: 'Query' object has no attribute
 'contains_column_references'
 }}}
 My custom field:

 {{{
 #!python
 class PkListField(Field):
 empty_strings_allowed = False
 description = "PK List"
 default_error_messages = {}

 def __init__(self, *args, max_recs=100, max_pk_size=5, sep=',',
 ordered=None, as_pks=True, model=None, manager='objects',
 pre_save_func=None, **kwargs):
 self.pk_list_model_manager = manager
 self.max_recs = max_recs
 self.max_pk_size = max_pk_size
 self.sep = sep
 self.as_pks = as_pks
 self.ordered = ordered
 self.pre_save_func = pre_save_func
 self._pk_list_model =

Re: [Django] #30563: Optimize django.forms.widgets.Media.add. (was: django.forms.widgets.Media.add Performance Issue)

2019-06-12 Thread Django

#30563: Optimize django.forms.widgets.Media.__add__.
--+
 Reporter:  didorothy |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Forms |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  media | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by felixxm):

 * keywords:  performance, unintended consequences => media
 * cc: Matthias Kestenholz (added)
 * stage:  Unreviewed => Accepted


Comment:

 I confirmed that 959d0c078a1c903cd1e4850932be77c4f0d2294d caused a
 performance issue. We should be able to optimize this by calling merge
 more often.

-- 
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.2fe493f564952a6b2f772fc7e3f0fcfe%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #30563: django.forms.widgets.Media.add Performance Issue

2019-06-12 Thread Django

#30563: django.forms.widgets.Media.__add__ Performance Issue
-+-
   Reporter:  didorothy  |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |
  Component:  Forms  |Version:  master
   Severity:  Normal |   Keywords:  performance,
   Triage Stage: |  unintended consequences
  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 While working with another project that make extensive use of
 `django.forms.widgets.Media` I discovered that the fix for ticket #30153
 has unintended consequences on the performance of `Media.__add__`. If the
 number of Media objects added grows beyond a certain point (not sure it
 may be machine specific) then the performance of all subsequent
 `Media.__add__` calls becomes terrible.

 This was causing page load times of several minutes on my development
 machine. I agree that you need to delay as long as possible as #30153
 intends but it seems that there probably should be an upper bound on this
 so that performance does not suddenly decrease.

 Here is some sample code that can reproduce the issue:

 {{{
 from django.forms import Media
 import datetime

 def create_media(MediaClass):
 '''Creates a simple Media object with only one or two items.'''
 return MediaClass(css={'all': ['main.css']}, js=['main.js'])

 start = datetime.datetime.now()
 media = create_media(Media)
 for i in range(10):
 media = media + create_media(Media)

 print('10 additions took: %s' % (datetime.datetime.now() - start))
 }}}

 On my machine several runs of this code result in times between 1:35 -
 1:44 (eg. 1 minute 35 seconds to 1 minute 44 seconds). However, taking
 away one zero from the number of media objects runs in under a second.
 Near as I can tell this has to do with the memory used to store these
 arrays and when it gets past a certain point the performance is awful.
 Since I am not sure if it is machine specific, for reference my machine is
 a i7-8700 with 64 GB RAM.

 Here is a sample that has a modified Media class that does not have theses
 issues:

 {{{
 from django.forms import Media
 import datetime

 def create_media(MediaClass):
 '''Creates a simple Media object with only one or two items.'''
 return MediaClass(css={'all': ['main.css']}, js=['main.js'])

 class CustomMedia(Media):
 def __add__(self, other):
 combined = CustomMedia()
 if len(self._css_lists) + len(other._css_lists) > 1000:
 combined._css_lists = [self._css, other._css]
 else:
 combined._css_lists = self._css_lists + other._css_lists

 if len(self._js_lists) + len(other._js_lists) > 1000:
 combined._js_lists = [self._js, other._js]
 else:
 combined._js_lists = self._js_lists + other._js_lists

 return combined

 start = datetime.datetime.now()
 media = create_media(CustomMedia)
 for i in range(10):
 media = media + create_media(CustomMedia)

 print('10 additions took: %s' % (datetime.datetime.now() - start))
 }}}

 With this change it again runs in under a second. If I increase the number
 of loops the performance seems to change at a much more expected level.

 I set an upper limit on the length allowed before a merge occurs. I'm not
 sure if the number of additions allowed should be a setting that can be
 adjusted to meet specific needs or if something that is just "reasonably"
 high is sufficient. It does appear that limiting the total number of items
 in the list to about 1000 works best on my machine. I'm also not sure that
 this is the best solution.

 Thanks for your consideration.

-- 
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.412a1c59baea95a7aa46e980197a2c1b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30449: Ordering problem in admin.RelatedFieldListFilter and admin.RelatedOnlyFieldListFilter

2019-06-12 Thread Django

#30449: Ordering problem in admin.RelatedFieldListFilter and
admin.RelatedOnlyFieldListFilter
-+-
 Reporter:  Moritz Pfeiffer  |Owner:  zeynel
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  Version:  2.2
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
  RelatedFieldListFilter,|
  RelatedOnlyFieldListFilter,|
  ordering   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  1
-+-
Changes (by felixxm):

 * needs_better_patch:  0 => 1


-- 
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/073.bb4b9aa20ba91c4c5bae3d01575f29d6%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30512: Update mail backend to use modern standard library parsing approach.

2019-06-12 Thread Django

#30512: Update mail backend to use modern standard library parsing approach.
-+-
 Reporter:  Joachim Jablon   |Owner:  Joachim
 Type:   |  Jablon
  Cleanup/optimization   |   Status:  assigned
Component:  Core (Mail)  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * needs_tests:  0 => 1


-- 
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.837fee6005720beac0e626f683b7f116%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30128: Using database functions with tzinfo=datetime.timezone(datetime.timedelta(...)) results in an incorrect query

2019-06-12 Thread Django

#30128: Using database functions with
tzinfo=datetime.timezone(datetime.timedelta(...)) results in an incorrect
query
-+-
 Reporter:  mvarnar  |Owner:  Can
 |  Sarıgöl
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  orm, postgresql, | Triage Stage:  Accepted
  timezone, datetime |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Can Sarıgöl):

 * needs_better_patch:  1 => 0


Comment:

 Thanks Carlton

-- 
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.da3d4eae399369660c044a0997898b11%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28053: Allow fields to specify arbitrary indexes via db_index=Index()

2019-06-12 Thread Django

#28053: Allow fields to specify arbitrary indexes via db_index=Index()
-+-
 Reporter:  Marc Tamlyn  |Owner:  Can
 |  Sarıgöl
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  indexes migrations   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Can Sarıgöl):

 Hi, thanks for your detailed explanation. Firstly, I wanted to be sure to
 understand you. Because of that I've issued a
 
[https://github.com/django/django/pull/11264/commits/9d27856794e0d4e50212e5a55285cd324f09fb5d
 commit]. I'm using {{{_get_index_type_kwargs}}} to getting kwargs for
 {{{_create_index_sql}}}. I applied it in this part. what do you think?

-- 
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.bfd7cd5edf73281d80368bef5000c4d8%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30128: Using database functions with tzinfo=datetime.timezone(datetime.timedelta(...)) results in an incorrect query

2019-06-12 Thread Django

#30128: Using database functions with
tzinfo=datetime.timezone(datetime.timedelta(...)) results in an incorrect
query
-+-
 Reporter:  mvarnar  |Owner:  Can
 |  Sarıgöl
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  orm, postgresql, | Triage Stage:  Accepted
  timezone, datetime |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * needs_better_patch:  0 => 1


Comment:

 Marking ''PnI'' since Mariusz asked for a simplification of the SQLite
 version. (Can, please uncheck when you've looked at that.)

-- 
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.06e9ebd3252015ad00f72dc065b26923%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30128: Using database functions with tzinfo=datetime.timezone(datetime.timedelta(...)) results in an incorrect query

2019-06-12 Thread Django

#30128: Using database functions with
tzinfo=datetime.timezone(datetime.timedelta(...)) results in an incorrect
query
-+-
 Reporter:  mvarnar  |Owner:  Can
 |  Sarıgöl
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  orm, postgresql, | Triage Stage:  Accepted
  timezone, datetime |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * stage:  Ready for checkin => Accepted


-- 
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.bbcd6eddabf8565be2603a3fc185157d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #30562: Document MariaDB support for GIS spatial lookups.

2019-06-12 Thread Django

#30562: Document MariaDB support for GIS spatial lookups.
+
   Reporter:  felixxm   |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Documentation |Version:  master
   Severity:  Normal|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 I doc'd MariaDB support for GIS database functions in this
 [https://github.com/django/django/pull/11469 PR]. We should also check and
 document MariaDB support for spatial lookups (see
 [https://mariadb.com/kb/en/library/mysqlmariadb-spatial-support-matrix/
 mariadb-spatial-support-matrix]).

-- 
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.5532aaee3b048c495b4753115e3bc18f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30128: Using database functions with tzinfo=datetime.timezone(datetime.timedelta(...)) results in an incorrect query

2019-06-12 Thread Django

#30128: Using database functions with
tzinfo=datetime.timezone(datetime.timedelta(...)) results in an incorrect
query
-+-
 Reporter:  mvarnar  |Owner:  Can
 |  Sarıgöl
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  orm, postgresql, | Triage Stage:  Ready for
  timezone, datetime |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * stage:  Accepted => Ready for checkin


Comment:

 OK, rebased and looking good. Thanks Can!

-- 
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.96a0392232e3da0af00c9dbd0433ca9e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30561: Time for peppering user passwords in Django?

2019-06-12 Thread Django

#30561: Time for peppering user passwords in Django?
---+--
 Reporter:  linluc |Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  Uncategorized  |  Version:  2.2
 Severity:  Normal |   Resolution:  invalid
 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 Carlton Gibson):

 * status:  new => closed
 * resolution:   => invalid


Comment:

 This is a discussion topic for the DevelopersMailingList.

-- 
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.804df7f1e07b2b43984b8759bb27af8b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30512: Update mail backend to use modern standard library parsing approach.

Re: [Django] #30564: Cannot create custom field that returns a queryset AND uses pre_save(). (was: Cannot create custom field that returns a queryset AND uses pre_save())

Re: [Django] #30355: Specifying custom manager doesn't work with prefetch

Re: [Django] #29043: test --keepdb says "Using existing test database" even if it's run for the first time

Re: [Django] #30564: Cannot create custom field that returns a queryset AND uses pre_save()

Re: [Django] #30563: Optimize django.forms.widgets.Media.add.

[Django] #30564: Cannot create custom field that returns a queryset AND uses pre_save()

Re: [Django] #30563: Optimize django.forms.widgets.Media.add. (was: django.forms.widgets.Media.add Performance Issue)

[Django] #30563: django.forms.widgets.Media.add Performance Issue

Re: [Django] #30449: Ordering problem in admin.RelatedFieldListFilter and admin.RelatedOnlyFieldListFilter

Re: [Django] #30512: Update mail backend to use modern standard library parsing approach.

Re: [Django] #30128: Using database functions with tzinfo=datetime.timezone(datetime.timedelta(...)) results in an incorrect query

Re: [Django] #28053: Allow fields to specify arbitrary indexes via db_index=Index()

Re: [Django] #30128: Using database functions with tzinfo=datetime.timezone(datetime.timedelta(...)) results in an incorrect query

Re: [Django] #30128: Using database functions with tzinfo=datetime.timezone(datetime.timedelta(...)) results in an incorrect query

[Django] #30562: Document MariaDB support for GIS spatial lookups.

Re: [Django] #30128: Using database functions with tzinfo=datetime.timezone(datetime.timedelta(...)) results in an incorrect query

Re: [Django] #30561: Time for peppering user passwords in Django?

18 matches

Site Navigation

Mail list logo

Footer information