Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

elastic::client::requests::document_index::Pending does not have method then() #414

Open
ronjakoi opened this issue Apr 23, 2020 · 2 comments

Comments

@ronjakoi
Copy link

My code starting on line 169:

let es = elastic::client::AsyncClientBuilder::new()
    .static_nodes(backend_url)
    .build()
    .unwrap(); // TODO
let timestamp = Utc::now();
let stats = Stats {
    core: "helsinki.fi".to_string(),
    status: res.response().status().as_u16(),
    query_time: entry_time.elapsed().whole_milliseconds(),
    timestamp: timestamp
        .format("%Y-%m-%d %H:%M:%S%.6f%:z")
        .to_string(),
    // TODO: remove stopwords
    original_query: clean_and_split_query(&q.1),
    query: clean_and_split_query(&q.1),
    stopword_count: 0,
    removed_stopwords: vec![],
};
let index_name = format!("searches-{}", timestamp.format("%Y%m%d"));
let send_fut = es.document().index_raw(index_name, stats).send();
send_fut.then(|_| ());

My error message:

   --> src/logging.rs:189:34
    |
189 |                         send_fut.then(|_| Ok(()));
    |                                  ^^^^ method not found in `elastic::client::requests::document_index::Pending`
    |
    = help: items from traits can only be used if the trait is in scope
    = note: the following trait is implemented but not in scope; perhaps add a `use` for it:
            `use futures::future::Future;`

I do have this use line in my file:

use futures::future::{ok, Ready, Future};
@ronjakoi
Copy link
Author

My elastic library version is 0.21.0-pre.5.

@mwilliammyers
Copy link
Collaborator

mwilliammyers commented May 29, 2020

Sorry for the late response.

It looks like from your other issue, elastic/elasticsearch-rs#102, you are using futures v0.3.0.

This repo is not compatible with futures v0.3 and we don't plan to support it as we have moved our development efforts over to the official crate which does support futures v0.3 (async/await syntax etc).

If you need to stick with this crate, you can try using tokio-compat or futures 0.1, but it might end up being more work than migrating over to the official client...

jszwedko added a commit to vectordotdev/vector that referenced this issue Oct 19, 2020
Updates to latest localstack tag. I need this for some of the S3+SQS
work, but figured I'd do it separately.

The biggest change is that localstack now exposes all services on the
same port, 4566, simplifying our setup.

Additional changes due to localstack changes:

I updated `aws_s3` sink tests to use "Identity" for Content-Encoding as
this appears to be the default encoding now

I added a sleep in `aws_kinesis_streams` test to allow localstack to
fully create the stream (it was getting `ResourceNotFound` errors when
the sink tried to publish via `PutRecords`). I tried a `wait_for` with
`DescribeStream`, but the stream was successfully returned by that
before it was ready, still.

I updated `aws_kinesis_firehose` to create the Elasticsearch domain as
localstack now lazily starts Elasticsearch upon domain creation.

I updated `aws_kinesis_firehose` tests to just deserialize requests
directly rather than using `elastic_responses` (which allowed me to drop
this dependency). The localstack update included an ES update which
caused me to run into elastic-rs/elastic#361
. I was going to update `elastic_responses` to include this change but
the `elastic_responses` crate was dropped in newer versions of that
repo.  I then attempted to switch to the actual client that repo
provides but ran into async issues with it depending on futures01
(elastic-rs/elastic#414). That Github issue
for that indicated to me that it seems like that repo was being
deprecated in-lieu of the official client. Given we only needed an
exceedingly small subset of functionality, I just decided to parse it
with `serde_json::Value` rather than switch to the new crate; however,
that seems like the preferred option for the future is an option for the
future if we come to need a more robust ES integration.

Signed-off-by: Jesse Szwedko <jesse@szwedko.me>
jszwedko added a commit to vectordotdev/vector that referenced this issue Oct 20, 2020
Updates to latest localstack tag. I need this for some of the S3+SQS
work, but figured I'd do it separately.

The biggest change is that localstack now exposes all services on the
same port, 4566, simplifying our setup.

Additional changes due to localstack changes:

I updated `aws_s3` sink tests to use "Identity" for Content-Encoding as
this appears to be the default encoding now

I added a sleep in `aws_kinesis_streams` test to allow localstack to
fully create the stream (it was getting `ResourceNotFound` errors when
the sink tried to publish via `PutRecords`). I tried a `wait_for` with
`DescribeStream`, but the stream was successfully returned by that
before it was ready, still.

I updated `aws_kinesis_firehose` to create the Elasticsearch domain as
localstack now lazily starts Elasticsearch upon domain creation.

I updated `aws_kinesis_firehose` tests to just deserialize requests
directly rather than using `elastic_responses` (which allowed me to drop
this dependency). The localstack update included an ES update which
caused me to run into elastic-rs/elastic#361
. I was going to update `elastic_responses` to include this change but
the `elastic_responses` crate was dropped in newer versions of that
repo.  I then attempted to switch to the actual client that repo
provides but ran into async issues with it depending on futures01
(elastic-rs/elastic#414). That Github issue
for that indicated to me that it seems like that repo was being
deprecated in-lieu of the official client. Given we only needed an
exceedingly small subset of functionality, I just decided to parse it
with `serde_json::Value` rather than switch to the new crate; however,
that seems like the preferred option for the future is an option for the
future if we come to need a more robust ES integration.

Signed-off-by: Jesse Szwedko <jesse@szwedko.me>
jszwedko added a commit to vectordotdev/vector that referenced this issue Oct 21, 2020
* chore(ci): Update localstack

Updates to latest localstack tag. I need this for some of the S3+SQS
work, but figured I'd do it separately.

The biggest change is that localstack now exposes all services on the
same port, 4566, simplifying our setup.

Additional changes due to localstack changes:

I updated `aws_s3` sink tests to use "Identity" for Content-Encoding as
this appears to be the default encoding now

I added a sleep in `aws_kinesis_streams` test to allow localstack to
fully create the stream (it was getting `ResourceNotFound` errors when
the sink tried to publish via `PutRecords`). I tried a `wait_for` with
`DescribeStream`, but the stream was successfully returned by that
before it was ready, still.

I updated `aws_kinesis_firehose` to create the Elasticsearch domain as
localstack now lazily starts Elasticsearch upon domain creation.

I updated `aws_kinesis_firehose` tests to just deserialize requests
directly rather than using `elastic_responses` (which allowed me to drop
this dependency). The localstack update included an ES update which
caused me to run into elastic-rs/elastic#361
. I was going to update `elastic_responses` to include this change but
the `elastic_responses` crate was dropped in newer versions of that
repo.  I then attempted to switch to the actual client that repo
provides but ran into async issues with it depending on futures01
(elastic-rs/elastic#414). That Github issue
for that indicated to me that it seems like that repo was being
deprecated in-lieu of the official client. Given we only needed an
exceedingly small subset of functionality, I just decided to parse it
with `serde_json::Value` rather than switch to the new crate; however,
that seems like the preferred option for the future is an option for the
future if we come to need a more robust ES integration.

Signed-off-by: Jesse Szwedko <jesse@szwedko.me>

* Remove elastic_responses from elasticsearch sink tests

Also fix port number for Elasticsearch and use normal localstack image.
I had been using `-full` to verify that not using it was causing
a failure but this turned out not to be the case.

Signed-off-by: Jesse Szwedko <jesse@szwedko.me>
mengesb pushed a commit to jacobbraaten/vector that referenced this issue Dec 9, 2020
* chore(ci): Update localstack

Updates to latest localstack tag. I need this for some of the S3+SQS
work, but figured I'd do it separately.

The biggest change is that localstack now exposes all services on the
same port, 4566, simplifying our setup.

Additional changes due to localstack changes:

I updated `aws_s3` sink tests to use "Identity" for Content-Encoding as
this appears to be the default encoding now

I added a sleep in `aws_kinesis_streams` test to allow localstack to
fully create the stream (it was getting `ResourceNotFound` errors when
the sink tried to publish via `PutRecords`). I tried a `wait_for` with
`DescribeStream`, but the stream was successfully returned by that
before it was ready, still.

I updated `aws_kinesis_firehose` to create the Elasticsearch domain as
localstack now lazily starts Elasticsearch upon domain creation.

I updated `aws_kinesis_firehose` tests to just deserialize requests
directly rather than using `elastic_responses` (which allowed me to drop
this dependency). The localstack update included an ES update which
caused me to run into elastic-rs/elastic#361
. I was going to update `elastic_responses` to include this change but
the `elastic_responses` crate was dropped in newer versions of that
repo.  I then attempted to switch to the actual client that repo
provides but ran into async issues with it depending on futures01
(elastic-rs/elastic#414). That Github issue
for that indicated to me that it seems like that repo was being
deprecated in-lieu of the official client. Given we only needed an
exceedingly small subset of functionality, I just decided to parse it
with `serde_json::Value` rather than switch to the new crate; however,
that seems like the preferred option for the future is an option for the
future if we come to need a more robust ES integration.

Signed-off-by: Jesse Szwedko <jesse@szwedko.me>

* Remove elastic_responses from elasticsearch sink tests

Also fix port number for Elasticsearch and use normal localstack image.
I had been using `-full` to verify that not using it was causing
a failure but this turned out not to be the case.

Signed-off-by: Jesse Szwedko <jesse@szwedko.me>
Signed-off-by: Brian Menges <brian.menges@anaplan.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants