Re: [Django] #29265: Docs about static files should explain benefits of using {% static %} template tag

[Django]

#29265: Docs about static files should explain benefits of using {% static %}
template tag
-+-
 Reporter:  Ryan Govostes|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  Version:  2.0
 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 Ryan Govostes):

 I don't strongly see the reason to bring up the option of hardcoding the
 URLs at all, rather than only recommending the best practice.

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

[Django] #29265: Docs about static files should explain benefits of using {% static %} template tag

[Django]

#29265: Docs about static files should explain benefits of using {% static %}
template tag
+
   Reporter:  Ryan Govostes |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Documentation |Version:  2.0
   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 |
+
 The [https://docs.djangoproject.com/en/2.0/howto/static-files/ guide on
 managing static files] says,

 In your templates, either hardcode the url like
 `/static/my_app/example.jpg` or, preferably, use the `static` template tag
 to build the URL for the given relative path by using the configured
 `STATICFILES_STORAGE` storage (this makes it much easier when you want to
 switch to a content delivery network (CDN) for serving static files).

 (Nit: The first "url" should be capitalized.)

 The text alludes to but does not really explain that if you use a static
 files storage backend that inherits from `ManifestStaticFilesStorage`, the
 `static` template tag will use the name of the hashed file in production,
 which enables longer-lived caches.

 Since the behavior is different in debug mode, I think many users will not
 even know about it, and fail to opt-in to the better caching behavior by
 hard-coding paths. (The files storage backend is turned on if the
 developer follows the WhiteNoise setup guide, or when using the Heroku app
 template, neither of which specifically calls out the need to use
 `static`.)

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

[Django] #29264: JS loading order in Admin-Change_form changes from model to model

[Django]

#29264: JS loading order in Admin-Change_form changes from model to model
---+
   Reporter:  yarharel |  Owner:  nobody
   Type:  Bug  | Status:  new
  Component:  Template system  |Version:  2.0
   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 _changeform_view
 
[https://github.com/django/django/blob/master/django/contrib/admin/options.py#L1538],
 the self.media and the adminForm media is being merged and then passed
 into rendering.
 This line merges two lists of css and js.
 The order of JS is important, and in this case (using Autocomplete-light
 package), it creates sitations where one change_form would load fine and
 another not to work fine because the js order changed.

 In my project, autocomplete-light package should load before admin (in
 INSTALLED_APPS), but the MediaWidget merge function
 [https://github.com/django/django/blob/master/django/forms/widgets.py#L99]
 switches the order sometimes.
 self.media always contains regular admin js and css while adminForm.media
 contains autocomplete-light js
 One example of result (`media = self.media + adminForm.media`)
 {{{
 self.media._js:
 : ['admin/js/vendor/jquery/jquery.js',
 'admin/js/jquery.init.js', 'admin/js/core.js',
 'admin/js/admin/RelatedObjectLookups.js', 'admin/js/actions.js',
 'admin/js/urlify.js', 'admin/js/prepopulate.js',
 'admin/js/vendor/xregexp/xregexp.js']

 adminForm.media._js:
 : ['autocomplete_light/jquery.init.js',
 'autocomplete_light/autocomplete.init.js',
 'autocomplete_light/vendor/select2/dist/js/select2.full.js',
 'autocomplete_light/vendor/select2/dist/js/i18n/en.js',
 'autocomplete_light/forward.js', 'autocomplete_light/select2.js',
 'admin/js/vendor/jquery/jquery.js', 'admin/js/jquery.init.js',
 'admin/js/calendar.js', 'admin/js/admin/DateTimeShortcuts.js']

 merge result -> media._js:
 : ['autocomplete_light/jquery.init.js',
 'autocomplete_light/autocomplete.init.js',
 'autocomplete_light/vendor/select2/dist/js/select2.full.js',
 'autocomplete_light/vendor/select2/dist/js/i18n/en.js',
 'autocomplete_light/forward.js', 'autocomplete_light/select2.js',
 'admin/js/vendor/jquery/jquery.js', 'admin/js/jquery.init.js',
 'admin/js/core.js', 'admin/js/admin/RelatedObjectLookups.js',
 'admin/js/actions.js', 'admin/js/urlify.js', 'admin/js/prepopulate.js',
 'admin/js/vendor/xregexp/xregexp.js', 'admin/js/calendar.js',
 'admin/js/admin/DateTimeShortcuts.js']
 }}}

 other change_form page:
 {{{
 self.media._js:
 : ['admin/js/vendor/jquery/jquery.js',
 'admin/js/jquery.init.js', 'admin/js/core.js',
 'admin/js/admin/RelatedObjectLookups.js', 'admin/js/actions.js',
 'admin/js/urlify.js', 'admin/js/prepopulate.js',
 'admin/js/vendor/xregexp/xregexp.js']

 adminForm.media._js:
 : ['autocomplete_light/jquery.init.js',
 'autocomplete_light/autocomplete.init.js',
 'autocomplete_light/vendor/select2/dist/js/select2.full.js',
 'autocomplete_light/vendor/select2/dist/js/i18n/en.js',
 'autocomplete_light/forward.js', 'autocomplete_light/select2.js']

 merge result -> media._js:
 : ['admin/js/vendor/jquery/jquery.js',
 'admin/js/jquery.init.js', 'admin/js/core.js',
 'admin/js/admin/RelatedObjectLookups.js', 'admin/js/actions.js',
 'admin/js/urlify.js', 'admin/js/prepopulate.js',
 'admin/js/vendor/xregexp/xregexp.js', 'autocomplete_light/jquery.init.js',
 'autocomplete_light/autocomplete.init.js',
 'autocomplete_light/vendor/select2/dist/js/select2.full.js',
 'autocomplete_light/vendor/select2/dist/js/i18n/en.js',
 'autocomplete_light/forward.js', 'autocomplete_light/select2.js']
 }}}

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

Re: [Django] #29248: Model field names can conflict with admin's field-box CSS class

[Django]

#29248: Model field names can conflict with admin's field-box CSS class
---+
 Reporter:  Phil Gyford|Owner:  Faheel Ahmad
 Type:  Bug|   Status:  assigned
Component:  contrib.admin  |  Version:  2.0
 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 Faheel Ahmad):

 Since classes in `forms.css` are in camel case, `fieldBox` seems to be the
 appropriate choice to me. If anyone has any suggestion regarding this do
 let me know. I'll have a PR ready in a few days.

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

Re: [Django] #29260: Remove UPDATE query when saving a new model instance with a primar key that has a default (was: Django makes an extra UPDATE query when custom PK is evaluating before save.)

[Django]

#29260: Remove UPDATE query when saving a new model instance with a primar key 
that
has a default
-+-
 Reporter:  user0007 |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 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 Tim Graham):

 * stage:  Unreviewed => 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/066.65609974c9a0e93a64a9516e8eaa9e90%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29260: Django makes an extra UPDATE query when custom PK is evaluating before save.

[Django]

#29260: Django makes an extra UPDATE query when custom PK is evaluating before
save.
-+-
 Reporter:  user0007 |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.0
  (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 Simon Charette):

 > A fix might try to detect if the primary key came from a default and if
 so, skip the update.

 I think we could use some kind of `self._state.adding and
 self._meta.pk.default` heuristics to automatically set `force_insert=True`
 on the last table/leaf child. That would break the following scenario
 though.

 {{{#!python
 a = Account(pk='known-uuid-pk')
 a.title = new_title
 a.save()  # expects an UPDATE here.
 }}}

 But I would argue that `force_update` should be passed in this case.

 That wouldn't solve the MTI issue described in #29129 but that would do
 for this case.

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

Re: [Django] #29258: Add an error message when passing an authentication backend class to login()'s backend argument where a string is expected (was: Better error message for passing authentication ba

[Django]

#29258: Add an error message when passing an authentication backend class to
login()'s backend argument where a string is expected
-+-
 Reporter:  Ryan Govostes|Owner:  Abeer
 Type:   |  Upadhyay
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.auth |  Version:  2.0
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Tim Graham):

 * needs_better_patch:  0 => 1
 * type:  New feature => Cleanup/optimization


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

Re: [Django] #29260: Django makes an extra UPDATE query when custom PK is evaluating before save.

[Django]

#29260: Django makes an extra UPDATE query when custom PK is evaluating before
save.
-+-
 Reporter:  user0007 |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.0
  (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 Tim Graham):

 I'm not sure if the issue can or should be fixed. For the model you gave,
 an instance will have an `id` from `default=uuid.uuid4`, so
 [https://docs.djangoproject.com/en/stable/ref/models/instances/#how-
 django-knows-to-update-vs-insert as documented] an `UPDATE` is tried
 
([https://github.com/django/django/blob/4554f9a783665d64b59c35b53ae71178e56ac783/django/db/models/base.py#L804-L805
 code]). A fix might try to detect if the primary key came from a `default`
 and if so, skip the update.

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

Re: [Django] #28919: Add support for Common Table Expression (CTE) queries

[Django]

#28919: Add support for Common Table Expression (CTE) queries
-+-
 Reporter:  Daniel Miller|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  QuerySet.extra   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by pwfff):

 Replying to [comment:5 Daniel Miller]:
 > I implemented generic CTE support for Django: https://github.com/dimagi
 /django-cte
 >
 > Would be happy to contribute this to be included with Django. Feedback
 is welcome.

 This has worked well for me, with the one exception of not being able to
 do an outer join since the library just uses extra_tables.

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

Re: [Django] #29262: Custom Left Outer Join in Queries

[Django]

#29262: Custom Left Outer Join in Queries
-+-
 Reporter:  Sassan Haradji   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  ORM Join | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 Duplicate of #26426, "Add a way to customize a QuerySet's joins"?

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

Re: [Django] #29263: Model.refresh_from_db() does not re-calculate annotation fields

[Django]

#29263: Model.refresh_from_db() does not re-calculate annotation fields
-+-
 Reporter:  Sam Frances  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.0
  (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 Tim Graham):

 * status:  new => closed
 * component:  Uncategorized => Database layer (models, ORM)
 * resolution:   => invalid


Comment:

 That's
 
[https://docs.djangoproject.com/en/stable/ref/models/instances/#django.db.models.Model.refresh_from_db
 by design]:

  Only fields of the model are reloaded from the database. Other database-
 dependent values such as annotations aren’t reloaded. Any @cached_property
 attributes aren’t cleared either.

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

[Django] #29263: Model.refresh_from_db() does not re-calculate annotation fields

[Django]

#29263: Model.refresh_from_db() does not re-calculate annotation fields
-+
   Reporter:  Sam Frances|  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Uncategorized  |Version:  2.0
   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  |
-+
 Running refresh_from_db() on a model which was retrieved using an
 annotated query, does not update any fields that were added by that
 annotated query.

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

Re: [Django] #29262: Custom Left Outer Join in Queries

[Django]

#29262: Custom Left Outer Join in Queries
-+-
 Reporter:  Sassan Haradji   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  ORM Join | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Sassan Haradji):

 SpamBayes doesn't let me to send this part because it's referring some
 google searches, so I post it in a gist:
 https://gist.github.com/sassanh/43ef664872c322a5f88434f10c5ce4ea


 Btw, there's an implicit message in every issue reported in open source
 community, the reporter doesn't ask any specific person to do it, as he
 has no right to do so as he's not paying them. What he wants by reporting
 an issue is trying to make consensus that the issue exists, get
 acknowledgement from the community that issue exists and someone (maybe
 himself, maybe a current contributor or maybe someone he's 2 years old now
 and is going to become a software developer in future) should solve it. An
 open issue/ticket means it is a step toward progression of the project, so
 while I do not ask current contributors to solve this issue, I do ask them
 to not abuse their privileges on this ticketing system and do not close it
 until it's either implemented in Django or someone provides good logic
 "why a developer using django framework can do whatever he wants without
 using custom outer joins."

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

Re: [Django] #29262: Custom Left Outer Join in Queries

[Django]

#29262: Custom Left Outer Join in Queries
-+-
 Reporter:  Sassan Haradji   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  ORM Join | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Sassan Haradji):

 4. I don't need union, I'm not trying to add rows to my main query, I'm
 trying to add a column to my query via outer join. So unfortunately union
 is not an option.

 5. Would be glad if you find it and share it here so that we can see if it
 solves the problem.

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

Re: [Django] #29262: Custom Left Outer Join in Queries

[Django]

#29262: Custom Left Outer Join in Queries
-+-
 Reporter:  Sassan Haradji   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  ORM Join | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Sassan Haradji):

 1. I like many need LEFT OUTER JOIN not INNER JOIN, if INNER JOIN was an
 efficient alternative to LEFT OUTER JOIN django itself would use it in its
 foreignkey joins, these joins don't do same thing and aren't an
 alternative for eachother.

 2. This is one from "10 years ago":
 https://code.djangoproject.com/ticket/7231

 3. `.raw()` may be good for some use cases, but I don't get it why should
 I lose all the features on a normal query (like count, filter, etc) just
 cause I wanna add a simple column by an outer join to that normal query.
 What I suggested as an "at least alternative" was an escape hatch that
 lets developer use normal queries (not raw queries) and patch them.
 A framework is just a tool in hands of the developer, I think everyone on
 earth trying to build a tool should consider that the tool should not
 limit its users, but it should give him new opportunities. Django provides
 lots of opportunities, but not providing an easy way to patch final sql it
 compiles is not a good thing. There are hard ways, I can subclass
 connection and query and change their behavior but there should be an easy
 way to do it after all (even if django supports left outer join). In
 documentation it should try to convince normal users to not use it and
 talk about security problems and instabilities it may introduce to code.
 But if someone needs it and knows what he's doing, then he should be able
 to do it.

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

Re: [Django] #29262: Custom Left Outer Join in Queries

[Django]

#29262: Custom Left Outer Join in Queries
-+-
 Reporter:  Sassan Haradji   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  ORM Join | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Josh Smeaton):

 A few things.

 1. I wasn't aware there were situations where a LEFT OUTER JOIN would have
 **better** performance than an INNER JOIN, since the LEFT JOIN looks at
 and includes more data. Are you able to provide the SQL for what is being
 generated and for what you want? The model definitions would also help.

 2. There have been lots of questions about customising joins. As far as I
 know, there have been no pull requests implementing such a thing in a
 reasonable manner. If you're aware of any pull requests it'd be good if
 you could share where those are so we can discuss the merits of each
 change.

 3. You're asking for an escape hatch that isn't the escape hatch that
 django is already providing. Django provides .raw() for exactly these
 purposes. If, for some technical reason, .raw() isn't appropriate, please
 discuss why so we can address those particular concerns.

 4. Is it possible to address your situation by using .union()? You can
 represent the FULL JOIN portion with 1 query, and the NULL join portion
 with a 2nd query, the .union() them together.

 5. There was some work done recently on annotating joins onto querysets,
 but I've been unable to find that ticket or patch.

 Now I am picking up from your ticket that you're frustrated. But no open
 source contributor anywhere has ever responded to the equivalent of "this
 situation is really bad for me so you must fix it for me" by jumping to do
 exactly that. If you want people to work, for free, on something you care
 about, then it's always better to approach the conversation in a more
 positive and friendly tone.

 We'd also be open to any contributions you or your company would be
 willing to make provided it made sense for the project.

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