Jinjasql Versions Save

Upgrade Severity: Critical

This release fixes a critical bug https://github.com/hashedin/jinjasql/issues/30. If your sql template uses string concatenation or other python operators, it can lead to sql injection.

This release is available on PyPI - https://pypi.org/project/jinjasql/0.1.8/

All Fixes:

1. JinjaSQL fails to bind parameters when an expression is used. See https://github.com/hashedin/jinjasql/issues/30
2. prepare_query now returns either a list or a dict. Earlier, it would return an OrderedDict or OrederedDict.values, and this broke certain database drivers which were expecting a plain list or dict. See https://github.com/hashedin/jinjasql/commit/543810a44e257573b6b6eacdf993a16e01505118
3. Prevent infinite loops when the same parameter name is bound multiple times with different values - like an in clause. https://github.com/hashedin/jinjasql/issues/16 and https://github.com/hashedin/jinjasql/issues/17. Credit @benrudolph
4. Support of asyncpg library, which expects bind parameters using the syntax $1, $2 etc. Credit @a.zubarev. See https://github.com/hashedin/jinjasql/commit/fc3ce9d1fb60ff666bbd551b5db5a70746d845b9
5. Allow prepare_query accept a precompiled jinja2 Template object in addition to a string. Credit @Photonios See https://github.com/hashedin/jinjasql/commit/30504f4645b60bdb6493091c1be5248726745f7a
6. Dropping support for python 3.4. It will likely still work, but we are no longer supporting it
7. Tests are now run using github actions

Fixes an issue with |inclause filter when a different parameter formatting style is requested. See https://github.com/hashedin/jinjasql/pull/6

Credit: @kxepal

The major feature is support for multiple param styles. Per PEP-249, database libraries can support 5 different styles of parameter types. These are :

1. format ANSI C printf format codes, e.g. ...WHERE name=%s. This is the default style.
2. qmark Question mark style, e.g. ...WHERE name=?
3. numeric Numeric, positional style, e.g. ...WHERE name=:1
4. named Named style, e.g. ...WHERE name=:name
5. pyformat Python extended format codes, e.g. ...WHERE name=%(name)s

You can specify the param_style by passing it to the constructor like this

jinja = JinjaSql(param_style='qmark')

Note that named and pyformat are special. The bind_parameters object returned by prepare_query will be a dictionary. For all other param styles, the bind_parameters object will be a list.

Other Changes

1. Added support for declarative tests via a YAML configuration file
2. Dropped support for python 2.6.x. This is because ordereddict is not available in python 2.6.x. Although workaround exist to add orderedict to python 2.6.x, the special handling wasn't worth it. If required, this can be added back fairly easily.

This release supports passing django request object as a context parameter to prepare_query

With this release, we are using Jinja's autoescape feature. As a result, the output of a macro is now considered SQL safe. This eliminates the need to manually invoke the |sqlsafe filter.

Earlier:

{% macro week(value) -%}
  some_sql_function({{value}})
{%- endmacro %}
SELECT 'x' from dual WHERE created_date > {{ week(request.start_date) | sqlsafe }}

Now:

{% macro week(value) -%}
  some_sql_function({{value}})
{%- endmacro %}
SELECT 'x' from dual WHERE created_date > {{ week(request.start_date) }}

Notice that you don't need |sqlsafe filter when invoking the week macro.