feat: handle datetime in nosql_apply_parameters_to_query

[fspot]

Before

nosql_apply_parameters_to_query(
    {'foo': '{{ bar }}'},
    {'bar': datetime(2020, 12, 31)}
)

would return

{'foo': '2020-12-31 00:00:00'}

(there was a forced cast to string, making it impossible to keep the date type)

After

it returns

{'foo': datetime.datetime(2020, 12, 31, 0, 0)}

(you can use bar | string or bar.isoformat() or bar.strftime(args) to get a string output)

[davinov]

Great! Here is one small question for something I've trouble understanding :

[davinov]

Great for checkboxes variables 👍

[davinov]

So easier ^^

By the way, I think we should progressively retire this parameter syntax in favor of Jinja one, which is simpler to read and write. Also, it's complex for users to have two possibilities that does the same thing.
Creating an issue to suggest that: #303

[davinov]

It's not instantly clear to me what do you mean by "render is not recursive".
May you explain that with an example? Thx

(I tried this to test nested arrays, but obtained as expected:

>>> env.from_string('{{ [punk, [ipa]] }}').render({'punk': ['pale', 'ale'], 'ipa': 10})
[['pale', 'ale'], [10]]

)

[fspot]

Sure !
There are actually 2 problems :
The 1st one is that render will apply a ast.literal_eval on the result (if the result is a str), and by doing so we lose the original type :

>>> env.from_string('{{ x }}').render({'x': 1})  # we expect 1
1
>>> env.from_string('{{ x }}').render({'x': '1'})  # we expect '1'
1  # <- meh

to handle this problem, a solution is to put strings inside quotes, this is what _prepare_parameters does.

>>> env.from_string('{{ x }}').render({'x': '"1"'})  # we expect '1'
'1'  # <- it works !

it also works if x is a list and we get one element from this list :

>>> env.from_string('{{ x[0] }}').render({'x': ['"1"', '"2"']})  # we expect '1'
'1'

but here's the 2nd problem :

>>> env.from_string('{{ x }}').render({'x': ['"1"', '"2"']})  # we expect ['1', '2']
['"1"', '"2"']  # <- meh

in this case, since the result is a list and not a str, jinja did not apply the literal_eval recursively. That's why we have to do it by hand, by calling _prepare_result.

[luc-leonard]

LGTM