#36727: Deprecate get_placeholder in favor of get_placeholder_sql
-------------------------------------+-------------------------------------
     Reporter:  Jacob Walls          |                    Owner:  Simon
         Type:                       |  Charette
  Cleanup/optimization               |                   Status:  closed
    Component:  Database layer       |                  Version:  dev
  (models, ORM)                      |
     Severity:  Normal               |               Resolution:  fixed
     Keywords:                       |             Triage Stage:  Ready for
                                     |  checkin
    Has patch:  1                    |      Needs documentation:  0
  Needs tests:  0                    |  Patch needs improvement:  0
Easy pickings:  0                    |                    UI/UX:  0
-------------------------------------+-------------------------------------
Changes (by Jacob Walls <jacobtylerwalls@…>):

 * resolution:   => fixed
 * status:  assigned => closed

Comment:

 In [changeset:"1a8fd5cf75bf855852f6bc2f75c3da9f7b145669" 1a8fd5cf]:
 {{{#!CommitTicketReference repository=""
 revision="1a8fd5cf75bf855852f6bc2f75c3da9f7b145669"
 Fixed #36727 -- Deprecated Field.get_placeholder in favor of
 get_placeholder_sql.

 The lack of ability of the get_placeholder call chain to return SQL and
 parameters separated so they can be mogrified by the backend at execution
 time
 forced implementations to dangerously interpolate potentially user
 controlled
 values.

 The get_placeholder_sql name was chosen due to its proximity to the
 previous
 method, but other options such as Field.as_sql were considered but
 ultimately
 rejected due to its different input signature compared to
 Expression.as_sql
 that might have lead to confusion.

 There is a lot of overlap between what Field.get_db_prep_value and
 get_placeholder_sql do but folding the latter in the former would require
 changing its return signature to return expression which is a way more
 invasive
 change than what is proposed here.

 Given we always call get_db_prep_value it might still be an avenue worth
 exploring in the future to offer a publicly documented interface to allow
 field
 to take an active part in the compilation chain.

 Thanks Jacob for the review.
 }}}
-- 
Ticket URL: <https://code.djangoproject.com/ticket/36727#comment:8>
Django <https://code.djangoproject.com/>
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 [email protected].
To view this discussion visit 
https://groups.google.com/d/msgid/django-updates/0107019ce47f329e-39c3dd24-cc96-4125-be2f-0bb952e2cc8e-000000%40eu-central-1.amazonses.com.

Reply via email to