#23426: migrations.RunSQL's function signature implies it won't do any parameter
substitution
-------------------------------------+-------------------------------------
Reporter: ris | Owner:
Type: | Markush2010
Cleanup/optimization | Status: closed
Component: Migrations | Version: master
Severity: Normal | Resolution: fixed
Keywords: migrations sql | Triage Stage: Accepted
runsql params escape | Needs documentation: 0
Has patch: 1 | Patch needs improvement: 1
Needs tests: 0 | UI/UX: 0
Easy pickings: 0 |
-------------------------------------+-------------------------------------
Comment (by Markush2010):
After trying to implement the parameter mapping as initially suggested by
Loic in multiple differnt ways, we came to the conclusion that every
attempt we made had some weakness that worked contrary to what people
would expect. Loic proposed passing parameters together with the SQL query
in a 2-tuple which is what I implemented now. Here's how it works (the
behavior for the `sql` and `reverse_sql` parameters are exactly the same):
----
If `sql` is a string, it is passed to
`schema_editor.connection.ops.prepare_sql_script()` where a multi
statement string is split into a list of single statements or a single
statement is returned as a list with only itself.
If `sql` is a list/tuple (they behave the same here and in the following
situations) Django will iterate over it and has '''xxx''' choices how to
interpret each element. If the element ...
1. ... is a string, Django will interpret it as a single statements (e.g.
no `;` that separates two `INSERT` statements)
2. ... is a list/tuple with 1 element Django behaves as in 1.
3. ... is a list/tuple with 2 elements Django will consider the first
element a single statement and the second the parameters as expected and
accepted by `cursor.execute()` and defined in
[http://legacy.python.org/dev/peps/pep-0249/ PEP-249]
4. ... is a list/tuple with 0 or >2 elements Django will raise a
`ValueError`
----
On IRC ThomasC raised the question that it might be worth taking a look
into 1. and 2. and pass the string through `prepare_sql_script()`. This
would involve some changes but should be possible. I'm not sure though if
this behavior is worth implementing. One usecase would be something like
`migrations.RunSQL([file1.read(), file2.read()])`
--
Ticket URL: <https://code.djangoproject.com/ticket/23426#comment:11>
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 post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/061.6503dc7b0df81f5090f0b976e5555560%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
