Currently, batch updates are broken in trunk, it's been like that since at
least r6. I don't know which version of Solr the feature was written in
mind with but it doesn't work with Solr 1.2+.

I'm not sure what to do about it as I'm not using it at all. Personally, I
would have nothing against deprecating and removing it, however having it
working again could possibly be an area for contributing to the project.

Original issue reported on code.google.com by [email protected] on 30 Aug 2009 at 6:32

What steps will reproduce the problem?

solr_conn = solr.SolrConnection('http://localhost:8080/solr')

solr_conn.query('test query', sort='field1 asc, field2 desc')

This doesn't work. I get a "400 Bad Request" response.

According to the docstrings, the sort param could be a string in the format
that SOLR expects, or a python list/tuple of field names.

I've attached a diff with a proposed fix for this.

Original issue reported on code.google.com by augusto%[email protected] on 26 May 2009 at 8:35

Attachments:

• solrpy_sort_patch.diff

I've added support for Python3 to solrpy. The root of the repo has been split into python2 and python3 subdirs. All the tests of the Python2 version have been appropriately updated and are 100% passing on Python3.

I've also updated setup.py so that it will install the correct version of solrpy given the version of Python the user is running.

I updated solrpy to run on python3 around Septmber, and the python3 version has been running on the Elvis Database since then. I only just updated the tests and setup this week, and feel it's ready to pull.

This version is currently hosted on Pypi as solrpy3, but I think it would be great to add these changes to the main solrpy dist. The repo is already set up to support both python 2 and python 3 installs from Pypi.

-Alex

Hey-lo,

I'm building a version of solrpy using conda for conda-forge. When possible, we try to include a link to the license file in the meta.yaml specification for the build; doing so requires the license be in the repository and that it be indexed in MANIFEST.in file so that it gets included in the source distribution. Would you consider adding a separate copy of the license info outside of the metadata where it's currently living and including it in the manifest?

It's easy to create mal-formed XML posts to Solr, and difficult to create
an efficient (single-POST) multi-document add or delete:

  conn = solr.SolrConnection('http://solr.example.net/')
  conn.begin_batch()
  conn.delete_many(['one', 'two'])
  conn.end_batch(commit=True)

will cause this XML to be POSTed:

  <delete><id>one</id></delete><delete><id>two</id></delete><commit/>

This should produce two POSTs:

  <delete><id>one</id><id>two</id></delete>

and:

  <commit/>

I'm using solrpy 0.5 (installed from PyPI using zc.buildout).

Original issue reported on code.google.com by fdrake on 6 May 2009 at 5:47

https://code.google.com/p/solrpy/issues/detail?id=34

What steps will reproduce the problem?

>>> import solr
>>> s = solr.SolrConnection('https://example.com/solr', post_headers={'x-api-key': 'xxxyyyzzz'})
>>> s.query("fred")

What is the expected output? What do you see instead?

I expect to see the x-api-key header on the server side

What version of the product are you using? On what operating system? pip install solrpy version on OS X

Please provide any additional information below.

here is a patch that fixes it for me

https://code.google.com/r/briantinglecdliborg-solrpyx/source/detail?r=d83b854e3b301aa1f433e52c7c5e617c1b4b303e

in the post method, we added retries due to badstatusline:

        attempts = 4
        while attempts: 
            caught_exception = False
            try:
                self.conn.request('POST', url, body.encode('utf-8'), headers)
                return check_response_status(self.conn.getresponse())
            except (socket.error,
                    httplib.ImproperConnectionState,
                    httplib.BadStatusLine):
                    # We include BadStatusLine as they are spurious
                    # and may randomly happen on an otherwise fine 
                    # SOLR connection (though not often)
                time.sleep(1)
                caught_exception = True
            except SolrHTTPException:
                msg = "HTTP error. %s tries left; retrying...\n" % attempts
                sys.stderr.write(msg)
                time.sleep(20)
                caught_exception = True
            if caught_exception:    
                self._reconnect()
                attempts -= 1
                if not attempts:
                    raise

Original issue reported on code.google.com by [email protected] on 24 Mar 2008 at 4:16

not sure why the first commit fixes things, based it on this:

https://github.com/key/solrpy/commit/5b5f14d17506a843290fccaf645d34f229a25714

That got it down to 4 errors, and then this http://stackoverflow.com/a/7790127/1763984 fixed those errors

What steps will reproduce the problem?
1. Issue a query
2. Use a condition like if response.numFound > 100
3. Python enters the condition nontheless
4. isinstance(response.numFound, long) == False

What is the expected output? What do you see instead?
The numFound attribute should be of type long, and similarly, start should 
be long too and maxScore float

Original issue reported on code.google.com by [email protected] on 18 Feb 2010 at 5:37

solrpy currently lacks a way to determine exactly what (encoded) query was 
sent to the SOLR server and what response was received from th SOLR server.

This is very inconvenient when developing against a potentially misbehaving 
SOLR server.

Attached here is a simple patch that adds a "debug" flag parameter to 
SolrConnection constructor.

Usage:

conn = solr.SolrConnection('http://localhost:8080/solr/', debug=True)

From then on, at each request passing through conn, solrpy will log at INFO 
level (using the logging module) both the passed in, encoded parameters and 
the resulting XML, making it easier to determine where a bug lies.

Original issue reported on code.google.com by [email protected] on 4 Feb 2010 at 10:03

Attachments:

• debug.patch

raw_query() turns all it's parameters into unicode objects, and then calls 
urllib.urlencode(), which can't really handle unicode in python 2.x, so it 
just turns non-ascii into ?'s. This makes it impossible to hand non-ascii to 
solr queries. If you encode to utf-8 before passing it to raw_query, the 
unicode() constructor throws an exception.

query() doesn't do this to its extra parameters, so to me it seems that 
raw_query shouldn't either. Patch attached.

Original issue reported on code.google.com by [email protected] on 19 Jan 2010 at 10:04

Attachments:

• raw-query-no-unicode.patch

Hello, We've been indexing with Solr.add_many successfully for a few years, but after an update to 1.0.0 we noticed our logs contained a copy of all documents.

It seems that the 1.0.0 package published on PyPi contains a print(''.join(lst)) ; that's really suprising as it's not in the repository (https://github.com/search5/solrpy/blob/master/solr/core.py#L518)

Can someone double-check ? If it is really there, please re-package a 1.0.1 release.

Starting from Solr 7.0 this parameter is very essential as defaultOperator was dropped from the schema. Because of the dot in the name, it is not easy and straightforward to specify it in solrpy using kwargs. So, let's support it natively.

This is extremely dangerous when processing field settings from untrusted sources: https://github.com/search5/solrpy/blob/master/solr/core.py#L1116

For Open ONI, we're considering just forking the repo to avoid this problem. A simple prototype has verified that it's trivial to construct a "value" which can run arbitrary code before the key check occurs. Given how often data is going to be stored from unknown sources, this just isn't an option for us.

Seems that the UTF-8 name Otis Gospodnetić causes a problem for the Unicode Decoder as it doesn't know what to do with the c with the acute accent.

Possible fix: https://github.com/search5/solrpy/blob/master/setup.py#L10 to: with open('README.md', "r", encoding="utf-8", errors="ignore") as f:

unicode is not good for some class, like Decimal, unicode will convert it to "Decimal xxx"，but not pure number string. This could cause error. However it can be solved by manually convert that variable to str. But sometimes it cannot be avoided. For example, delete just one field: { "id": 1, "fieldToBeDelete": {"set": None} }

"None" will be serialized to "None" but not null, and Solr server will accept it as a new value，rather than to delete this field. This may be terrible.

Can you fix this problem? or moreover provide a way to replace 'unicode' by some option?