odoo/upgrade-util#339

Created by Upgrade, Christophe Simonis (chs)
Merged at 58851b2fd74b79ea7ee6798479d97e9a7b5428ee

Statuses:

label
odoo-dev:master-explode-formatter-chs
head
4eacbc8ce85708ce81a94b0b6f85ab3d4ad78930
merged
5 months ago by Upgrade, Christophe Simonis (chs)
odoo/upgrade-util
master #339

[IMP] util.explode_query{,_range}: only format the `{parallel_filter}` placeholder

The usage of str.format to inject the parallel filter used to explode queries is not robust to the presence of other curly braces. Examples:

  1. JSON strings (typically to leverage their mapping capabilities):

See 79f3d7184285e39b04a6c032aec0e05de6565fe8, where a query had to be modified to accommodate that.

  1. Hardcoded sets of curly braces:
>>> "UPDATE t SET c = '{usage as literal characters}' WHERE {parallel_filter}".format(parallel_filter="…")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
KeyError: 'usage as literal characters'

Which can be (unelegantly) solved adding even more braces, leveraging one side effect of str.format:

>>> "UPDATE t SET c = '{{usage as literal characters}}' WHERE {parallel_filter}".format(parallel_filter="…")
"UPDATE t SET c = '{usage as literal characters}' WHERE …"
  1. Hardcoded single unpaired curly braces (AFAICT no way to solve this):
>>> "UPDATE t SET c = 'this is an open curly brace = {' WHERE {parallel_filter}".format(parallel_filter="…")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: unexpected '{' in field name
>>> "UPDATE t SET c = 'this is a close brace = }' WHERE {parallel_filter}".format(parallel_filter="…")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: Single '}' encountered in format string

To circumvent this, we now use a dedicated Formatter that only handle the {parallel_filter} placeholder. This has the advantage of still deduplicate the doubled curly braces (see point 2 above) and thus being retro-compatible.

This doesn't solve the single unpaired curly braces case, but this is rare enough to be handled by other means.


Alternative to #142