Each builder struct currently takes ownership of Elasticsearch, with instantiation of a builder struct from the root or a namespace client accepting a clone of the Elasticsearch instance on which the associated function is called. For example, in the case of search
#[derive(Clone, Debug)]
#[doc = "Builder for the [Search API](https://www.elastic.co/guide/en/elasticsearch/reference/master/search-search.html). Returns results matching a query."]
pub struct Search<'a, B> {
client: Elasticsearch,
parts: SearchParts<'a>,
// ....
}
impl<'a, B> Search<'a, B>
where
B: Body,
{
#[doc = "Creates a new instance of [Search] with the specified API parts"]
pub fn new(client: Elasticsearch, parts: SearchParts<'a>) -> Self {
Search {
client,
parts,
// ...
}
}
}
impl Elasticsearch {
#[doc = "Returns results matching a query."]
pub fn search<'a>(&self, parts: SearchParts<'a>) -> Search<'a, ()> {
Search::new(self.clone(), parts)
}
}
With an instance of Elasticsearch now instantiated with a Transport that has a ConnectionPool of Connections with which to make API calls to Elasticsearch, it is desirable for builder structs to share the same ConnectionPool, such that in the future, when other ConnectionPool implementations can refresh the collection of connections, this would be reflected in all builders.
Possible implementations
Same lifetime as SearchParts<'a>
Making Elasticsearch now a reference, &Elasticsearch, requires giving it an explicit lifetime. One implementation of this would be to give it the same lifetime as SearchParts<'a>
I think that &Elasticsearch should have a different lifetime to *Parts<'a> (second implementation) because it can be alive for a different (longer) scope than both *Parts<'a> and the returned builder struct.
Each builder struct currently takes ownership of
Elasticsearch
, with instantiation of a builder struct from the root or a namespace client accepting a clone of theElasticsearch
instance on which the associated function is called. For example, in the case ofsearch
With an instance of
Elasticsearch
now instantiated with aTransport
that has aConnectionPool
ofConnections
with which to make API calls to Elasticsearch, it is desirable for builder structs to share the sameConnectionPool
, such that in the future, when otherConnectionPool
implementations can refresh the collection of connections, this would be reflected in all builders.Possible implementations
Same lifetime as
SearchParts<'a>
Making
Elasticsearch
now a reference,&Elasticsearch
, requires giving it an explicit lifetime. One implementation of this would be to give it the same lifetime asSearchParts<'a>
New lifetime
An alternative is introducing a new lifetime for
&Elasticsearch
I think that
&Elasticsearch
should have a different lifetime to*Parts<'a>
(second implementation) because it can be alive for a different (longer) scope than both*Parts<'a>
and the returned builder struct.