Closed jeffdyke closed 5 years ago
Thanks for your detailed report!
I prefer a natural way rather than a workaround for maintaining the backward compatibility. So your change seems to be better than inferring the collection name from URL.
By the way, unit tests of this library are very limited for now. We might have to add functional tests using the embedded solr or docker to find out this kind of issues earlier.
Thanks for the quick response @takezoe and i agree with you, i don't want to infer a collection from a URI, i'll keep working on my fork and test different approaches and then submit back for PR and see if i have some time to work up more unit tests.
Oh and btw, this is not a breaking change.
I have noticed in a newer version of the ApacheSolrClient it seems to want the collection being written to as an argument and also one for commiting, otherwise an NPE, or 404 is thrown depending on the way the client is instantiated. I have a simple schema that conforms to this case class:
The following are my results with unchanged solr-scala-client (running sbt console):
Using
addToCollection
, same imports/data as aboveWith modified code seen here: https://github.com/takezoe/solr-scala-client/compare/master...jeffdyke:master
add
andaddToCollection
will return properly, when supplied a collection, but you can't send them the collection as part of the URL, that will result in a 404 as it tries to append it.I'm happy to open an official PR, but would like to get your thoughts on this. If i were to change it, i would make it a breaking change, or you could infer the collection from the URL, but i don't like that idea to much.