Skip to content

Releases: sripathikrishnan/jinjasql

Release 0.1.8

28 May 00:43
Compare
Choose a tag to compare

Upgrade Severity: Critical

This release fixes a critical bug #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 #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 543810a
  3. Prevent infinite loops when the same parameter name is bound multiple times with different values - like an in clause. #16 and #17. Credit @benrudolph
  4. Support of asyncpg library, which expects bind parameters using the syntax $1, $2 etc. Credit @a.zubarev. See fc3ce9d
  5. Allow prepare_query accept a precompiled jinja2 Template object in addition to a string. Credit @Photonios See 30504f4
  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

Release 0.1.6

21 Nov 19:30
Compare
Choose a tag to compare

Fixes an issue with |inclause filter when a different parameter formatting style is requested. See #6

Credit: @kxepal

Release 0.1.5

09 Nov 15:24
Compare
Choose a tag to compare

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.

Release 0.1.4

26 Oct 15:17
Compare
Choose a tag to compare

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

Release 0.1.3

26 Oct 06:24
Compare
Choose a tag to compare

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.