Skip to content

Conversation

@carols10cents
Copy link
Contributor

There are some parts of the tests that should probably be part of the arrow-flight crate instead, but that can be done in a future PR. Everything here is in the integration tests.

@github-actions
Copy link

Copy link
Contributor

@nevi-me nevi-me left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM subject to CI, just comments that don't need any further action beyond response/confirmation

Ok(())
}

// TODO: should this be extended, abstracted, and moved out of test code and into production code?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

my intuition says no, as I'm assuming that there'd be different ways of implementing authentication.
I have however not used Flight, so if the basic auth scenario is always this, we could move this into arrow-flight.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The C++ Flight client provides this Authenticate function and the ability to specify a ClientAuthHandler, but I'm not sure if that's the abstraction desired in Rust 🤷‍♀️

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we can always add it later to the core Rust library -- for now, having code in the example that does the work that people can use / follow seems pretty good to me

@carols10cents
Copy link
Contributor Author

The archery unit tests are failing with this error:

E   ImportError: cannot import name 'HTTPHeaderDict'

In the step before the unit tests are run, there's this:

ERROR: After October 2020 you may experience errors when installing or updating packages. This is because pip will change the way that it resolves dependency conflicts.
Successfully installed MarkupSafe-1.1.1 archery attrs-20.3.0 certifi-2020.11.8 cffi-1.14.3 chardet-3.0.4 click-7.1.2 cryptography-3.2.1 defusedxml-0.6.0 deprecated-1.2.10 gitdb-4.0.5 gitpython-3.1.11 idna-2.10 importlib-metadata-2.0.0 iniconfig-1.1.1 jinja2-2.11.2 jira-2.0.0 numpy-1.18.5 oauthlib-3.1.0 packaging-20.4 pandas-0.25.3 pathlib2-2.3.5 pbr-5.5.1 pluggy-0.13.1 py-1.9.0 pycparser-2.20 pygithub-1.53 pyjwt-1.7.1 pyparsing-2.4.7 pytest-6.1.2 python-dateutil-2.8.1 python-dotenv-0.15.0 pytz-2020.4 requests-2.24.0 requests-oauthlib-1.3.0 requests-toolbelt-0.9.1 responses-0.12.0 ruamel.yaml-0.16.12 ruamel.yaml.clib-0.2.2 semver-2.13.0 six-1.15.0 smmap-3.0.4 toml-0.10.2 toolz-0.11.1 urllib3-1.26.0 wrapt-1.12.1 zipp-1.2.0

We recommend you use --use-feature=2020-resolver to test your packages with the new resolver before it becomes the default.

requests 2.24.0 requires urllib3!=1.25.0,!=1.25.1,<1.26,>=1.21.1, but you'll have urllib3 1.26.0 which is incompatible.

I'm not very familiar with Python but given it's November this seems likely...? I'm not sure the correct way to fix this, and I don't see any open PRs about it from a quick skim?

The other failing test job says it's out of disk space, is there anything I can do about that?

@carols10cents carols10cents force-pushed the flight-integration-tests branch from bf27024 to 087cedc Compare November 13, 2020 14:54
@carols10cents
Copy link
Contributor Author

Ok, so, now the integration test job got cancelled after 360 min, and suspiciously it appears to be cancelled during the Flight tests after C++ -> C++ and C++ -> Java, right when I would expect C++ -> Rust to be, sooooo it's possible that it's my fault somehow. I will investigate more on Monday.

Copy link
Contributor

@alamb alamb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is really cool @carols10cents . Thank you!

One very minor suggestion is to update https://github.com/integer32llc/arrow/blob/flight-integration-tests/rust/integration-testing/README.md to include mention of the new binaries, flight-test-integration

Ok(())
}

// TODO: should this be extended, abstracted, and moved out of test code and into production code?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we can always add it later to the core Rust library -- for now, having code in the example that does the work that people can use / follow seems pretty good to me

@alamb
Copy link
Contributor

alamb commented Nov 14, 2020

Once the integration tests are passing, I think this PR is good to merge

Copy link
Member

@jorgecarleitao jorgecarleitao left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Really impressive, @carols10cents . Thank you so much for this ❤️

@carols10cents carols10cents force-pushed the flight-integration-tests branch from 429e6be to b62184e Compare November 19, 2020 14:17
@carols10cents carols10cents marked this pull request as draft November 19, 2020 14:19
@github-actions github-actions bot added the needs-rebase A PR that needs to be rebased by the author label Nov 26, 2020
@carols10cents
Copy link
Contributor Author

I've decided to stop wasting CI time on this because it's not nearly ready :) Will reopen a new PR when it is.

@jorgecarleitao
Copy link
Member

Just to say that I really appreciate that you are working on this. Thank you so much ❤️

nevi-me pushed a commit that referenced this pull request Dec 12, 2020
…ies with that of a RecordBatch

This PR contains a series of refactorings to extract code from the IPC `FileWriter` and `StreamWriter` that generates `EncodedData` instances. I highly recommend reviewing commit-by-commit, I tried to make the changes fairly mechanical and easy to understand at each step.

With those refactorings, it becomes easier to reuse the code with Flight too, so that when we're generating `FlightData` for a `RecordBatch`, we get the `FlightData` for the batch's dictionaries too.

This will help in getting the Flight integration tests that include dictionaries to pass... I'm also having some unrelated protocol problems over in [this PR I'm working on](#8641) but this work will help there.

Closes #8826 from carols10cents/refactor-file-stream-writer

Authored-by: Carol (Nichols || Goulding) <carol.nichols@gmail.com>
Signed-off-by: Neville Dipale <nevilledips@gmail.com>
alamb pushed a commit to apache/arrow-rs that referenced this pull request Apr 20, 2021
…ies with that of a RecordBatch

This PR contains a series of refactorings to extract code from the IPC `FileWriter` and `StreamWriter` that generates `EncodedData` instances. I highly recommend reviewing commit-by-commit, I tried to make the changes fairly mechanical and easy to understand at each step.

With those refactorings, it becomes easier to reuse the code with Flight too, so that when we're generating `FlightData` for a `RecordBatch`, we get the `FlightData` for the batch's dictionaries too.

This will help in getting the Flight integration tests that include dictionaries to pass... I'm also having some unrelated protocol problems over in [this PR I'm working on](apache/arrow#8641) but this work will help there.

Closes #8826 from carols10cents/refactor-file-stream-writer

Authored-by: Carol (Nichols || Goulding) <carol.nichols@gmail.com>
Signed-off-by: Neville Dipale <nevilledips@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants