v3.3.0

What's Changed

• Download with slug or DOI by @alycejenni in #58
• Add an XLSX file download option by @jrdh in #59
• Release 2022-04-25 by @alycejenni in #60

Full Changelog: v3.2.1...v3.3.0

v3.2.1

What's Changed

• Switch to setup.cfg by @jrdh in #53
• Release 2022-03-28 by @alycejenni in #56

Full Changelog: v3.2.0...v3.2.1

v3.2.0

What's Changed

• Add an interface hook to modify request before writing download file by @alycejenni in #50
• Data transformations by @alycejenni in #51

Full Changelog: v3.1.3...v3.2.0

v3.1.3

What's Changed

• Remove paster mentions from README by @jrdh in #48
• Extend the elasticsearch client timeout to 30s instead of 10s by @alycejenni in #49

Full Changelog: v3.1.2...v3.1.3

v3.1.1

Timeout fixes, documentation adjustments, formatting.

v3.1.0

• DwC-A downloader (#44):

Adds a new download format - DarwinCore Archives.

• supports core extensions and non-core extensions (currently only configured to use GBIF extensions)
• extensions can be set in configs and overridden in request args
• optionally integrates with ckanext-attribution and ckanext-query-dois to generate metadata (uses defaults if not available)
• also adds format_args request arg for all download types, for passing in extra options specific to the format

v3.0.0

• Send HTML download emails (#42)

This release contains breaking changes to the IVersionedDatastoreDownloads interface`.

v2.0.0

• Upgrades this extension to work with Python 3 and CKAN 2.9.x
• Drops Python 2 support

v0.0.5

Respect the current version's column order before other old versions

In commit b9b64911c2c0f5ecc4c3e0c77c1e009e3c9095a2 we added code to
handle a specific ordering problem. The problem was:

---
in v1 a single record is added:
  {'x': -5, 't': 'hi', 'a': true, 'b': 29}

in v2 another single record is added and the existing record is kept:
  {'e': false}

therefore the fields for v1 are: ['x', 't', 'a', 'b']
and for v2 the fields are: ['x', 't', 'a', 'b', 'e']

essentially, the order of the original v1 fields is maintained with the
addition of a new field in v2.
---

This works great for partial updates, but not so well if:

in v1 a single record is added:
  {'x': -5, 't': 'hi', 'a': true, 'b': 29}

in v2 another single record is added but the existing record is
replaced:
  {'b': 29, 'a': true, 't': 'hi', 'x': -5}

we'd expect v1's fields to look like this: ['x', 't', 'a', 'b']
and v2's fields to look like this: ['b', 'a', 't', 'x']. But they'd
actually be the same because v1's field order is used before v2s. This
commit fixes this problem by reversing the order so that we use the
order from the version we're querying first and then work backwards,
adding the fields from previous versions as we go. This fixes this
problem and will result in ['e', 'x', 't', 'a', 'b'] for v2 in the first
problem outline - which is perfectly acceptable I think.

v0.0.4

Remove falsey column names during validation

Empty string columns exist in the db, that makes sense, people
upload garbage. However, null column names also exist, not sure
how though. Either way, they can all be removed here.