lp:~pythonxy/pythonxy-upstream/blaze-into

Created by dacoex on 2015-02-09 and last modified on 2017-10-24
Get this branch:
bzr branch lp:~pythonxy/pythonxy-upstream/blaze-into

Branch merges

Related bugs

Related blueprints

Branch information

Owner:
Python XY
Project:
Upstream Package Updates for PythonXY
Status:
Development

Import details

Import Status: Reviewed

This branch is an import of the HEAD branch of the Git repository at git://github.com/ContinuumIO/into.git.

The next import is scheduled to run in 5 hours.

Last successful import was 44 minutes ago.

Import started 45 minutes ago on russkaya and finished 44 minutes ago taking 25 seconds — see the log
Import started 6 hours ago on pear and finished 6 hours ago taking 20 seconds — see the log
Import started 12 hours ago on pear and finished 12 hours ago taking 20 seconds — see the log
Import started 18 hours ago on pear and finished 18 hours ago taking 20 seconds — see the log
Import started on 2017-12-14 on pear and finished on 2017-12-14 taking 20 seconds — see the log
Import started on 2017-12-14 on pear and finished on 2017-12-14 taking 15 seconds — see the log
Import started on 2017-12-13 on russkaya and finished on 2017-12-13 taking 25 seconds — see the log
Import started on 2017-12-13 on russkaya and finished on 2017-12-13 taking 25 seconds — see the log
Import started on 2017-12-13 on pear and finished on 2017-12-13 taking 15 seconds — see the log
Import started on 2017-12-13 on pear and finished on 2017-12-13 taking 20 seconds — see the log

Recent revisions

522. By Joe Jevnik <email address hidden> on 2017-10-24

BUG: allow other connectables to be passed as the bind param

521. By Eddie Hebert <email address hidden> on 2017-10-18

ENH: Map full range of supported precision values.

Postgres maps float(1) through float(24) to real, and float(25) to float(53) to
double precision. Map those ranges to float32 and float64, respectively.

520. By Eddie Hebert <email address hidden> on 2017-10-18

BUG: Fix reflection Postgres double precision columns.

A double precision column in a Postrges table, whose dshape specified a dtype of
`float64` for that column, would return a decimal dtype.

Fix by defining a group of types which are 'precision' types, and check for
membership in that before attempting to lookup the typeengine typ in
`blaze.backends.sql.revtypes`

Without the fix applied the newly added test fails with the following assertion
error, when comparing the `discover` of the `bind` with the expected values:
```
    @assert_dshape_equal.register(object, object)
    def _base_case(a, b, path=None, **kwargs):
> assert a == b, '%s != %s\n%s' % (a, b, _fmt_path(path))
E AssertionError: decimal[precision=53, scale=None] != float64
E path: _.measure['a']
```

Also, added `sa.Float` as a precision type, which fixes
`sa.Float(precision=24)`; this allows removal of the `xfail` marking in
`odo/backends/test/test_sql::test_types`.

519. By Eddie Hebert <email address hidden> on 2017-10-16

TST: Mark sa.Float(precision=24) case as xfail.

Instead of commenting out, mark the failing sa.Float(precision=24) case as
xfail.

518. By Eddie Hebert <email address hidden> on 2017-10-16

BUG: Fix discover for sa.TIMESTAMP.

`discover` was returning a bytes dtype for the `sa.TIMESTAMP` instead of
`datetime_`.

That bug was because the SQLAlchemy dialect for MSSQL currently directly imports
`sa.TIMESTAMP`, causing a collision in `odo.backends.sql.revtypes`.

Fix by 1) creating a subclass of `mssql.TIMESTAMP` to use as the key in
`revtypes` so that it does not overwrite `sa.TIMESTAMP` 2) assign that subclass
to the mssql dialect's `'TIMESTAMP'` (using `ischema_names`), so that the
subclass will be returned by the type engine instead of `mssql.TIMESTAMP`.

The added test for the (`sa.TIMESTAMP`, `datetime_`) without the fix applied
would result in this error:
```
a = Bytes(), b = DateTime(tz=None), path = ('.measure', "['ts']", '.ty')
kwargs = {'check_dim': True, 'check_record_order': True}

    @assert_dshape_equal.register(object, object)
    def _base_case(a, b, path=None, **kwargs):
> assert a == b, '%s != %s\n%s' % (a, b, _fmt_path(path))
E AssertionError: bytes != datetime
E path: _.measure['value'].ty
```

This patch includes checks for the other types besides `sa.TIMESTAMP` for better
protection against the general case of failures when using `revtypes` to map
SQLAlchemy types to dtypes.

Those extra cases exposed an issue with `sa.Float(precision=24)`.
That case is commented out to keep the fix of this patch on the `sa.TIMESTAMP` mapping.
(I would have used `pytest.param` to mark it xfail, but pytest for this project needs to be
upgraded first.)

See:
https://github.com/blaze/odo/issues/567
https://github.com/blaze/odo/pull/568
https://bitbucket.org/zzzeek/sqlalchemy/issues/4092/type-problem-with-mssqltimestamp
https://github.com/blaze/blaze/pull/1656

517. By Eddie Hebert <email address hidden> on 2017-10-14

TST: Upgrade pytest to latest.

Rerunning the tests with the upgraded pytest produces the same number of passing
and xfailed tests.

With pytest 3.2.3, 5 warnings are now shown.
pytest 3.1.0 changed behavior so that warnings are captured and displayed.
https://docs.pytest.org/en/latest/changelog.html#id81

The impetus for upgrading is that in another patch, using `pytest.param` to mark a
specific parameter as an xfail would have been useful; `pytest.param` was added
in 3.1.0

516. By Richard Postelnik <email address hidden> on 2017-07-24

#515 switch to Numeric type

515. By David Lakata <email address hidden> on 2017-07-24

Fix typo in docs

514. By Michael Herman <email address hidden> on 2017-07-24

updated blaze link

513. By dhirschf <email address hidden> on 2017-07-24

Don't rely on ResultProxy.keys for column names

These names can be truncated/translated so won't always map back to the
column names

Branch metadata

Branch format:
Branch format 7
Repository format:
Bazaar repository format 2a (needs bzr 1.16 or later)
This branch contains Public information 
Everyone can see this information.

Subscribers

No subscribers.