0.5.6

This release fixes any() and len() nested inside another any(). These queries used to fail with an SQL error or return no rows. They now return the same rows on SQLite, PostgreSQL and the evaluator (proxied) path. No query that worked before changes behavior.

What's Changed

Nested any() and len() — @dsblank (#6)

• A collection inside a collection's condition. any(e for e in events if any(e.citations)) and any(e for e in events if e.place.title == 'Chicago') failed with no such column: event.json_data. They now compile.
• A list inside a list. any(r for r in event_ref_list if any(a for a in r.attribute_list if a.value == 'witness')) produced invalid SQL. Each nesting level now gets its own alias (je, je1, je2, …).
• A list on an array element. any(r for r in event_ref_list if any(r.citation_list)) checked the person's own citation_list instead of each event reference's, so it matched nobody. len() had the same problem. Both now check each element.
• The same collection nested in itself. any(p for p in enclosing_places if any(p.enclosing_places)) (a place whose encloser is itself enclosed) and any(a for a in associations if len(a.associations) > 1) matched nobody: the inner query read its own row instead of the outer one. Each nesting level now gets its own alias (place__target, place__target1, …).

Tests

New tests run each nested query as SQL and through the evaluator, and check that both return the expected rows. They cover crossing tables, nesting a collection in itself up to three levels, and lists inside lists. Set GOQL_TEST_POSTGRES_DSN to also run them on PostgreSQL. The tests copy their fixture into temporary tables and roll back, so they don't touch existing data.

Contributors

• @dsblank

Full Changelog: 0.5.5...0.5.6