self.query_server is a pysolr object, and in most cases gets its auth attribute set in the constructor. This line modifies that for a certain case. And then afterwards it gets used internally by pysolr
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In that case though, shouldn't it use push_server_auths[0] since it's using the push server? OTOH I can also see the case for having two sets of credentials for the same host; a set of push credentials and a set of query credentials while the host is the same.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yea the use-case is along those lines. But it still is a bit awkward, I wasn't sure if a better way. Here's the situation (in some non-oss code we have). Calling code was originally:
make_solr_from_config(solr_mail_server)
and it was only doing queries, so push_server_auths[0] logic was being used. It needed auth and I wanted to provide the query auth since it was only doing queries:
db/8568
This all looks good. I have the tiniest note: It looks like
self.query_server.authis unused?self.query_serveris a pysolr object, and in most cases gets itsauthattribute set in the constructor. This line modifies that for a certain case. And then afterwards it gets used internally by pysolrOk, that makes sense.
In that case though, shouldn't it use
push_server_auths[0]since it's using the push server? OTOH I can also see the case for having two sets of credentials for the same host; a set of push credentials and a set of query credentials while the host is the same.Yea the use-case is along those lines. But it still is a bit awkward, I wasn't sure if a better way. Here's the situation (in some non-oss code we have). Calling code was originally:
and it was only doing queries, so
push_server_auths[0]logic was being used. It needed auth and I wanted to provide the query auth since it was only doing queries:so I ended up with this
merged