Consider merge with Search API Solr 8.x-2.x

Yes, I'm all for that. It seems the necessary code is small enough to make no large impact, but it's very handy to have within the module so people can reliably find the functionality.

Agreed with this as well, have been using search_api_solr_datasource quite successfully with views + panels + facets in the past few weeks with zero issues.

If you two think it would be worthwhile to roll this into Search API Solr, then I'm ok with it. With the work that @drunken_monkey put into it today I think it will be much closer to being ready for that to happen. I'll do a thorough review of the changes he's proposed after work tonight, but I can tell from looking through them that they fix a lot of things that I've thought about changing.

If you want to make me a co-maintainer when that happens, that would be awesome. I'm more than willing to continue being responsible for it and to help out with other issues.

I'm still honored that you're considering this as a submodule. The truth is that I haven't put any time into it since May. I shifted gears during the summer and started working hard on the other modules that I already maintain. There was one in particular that I'd neglected for a while and has required a lot of my contribution time. I realize that's probably not welcome news from the standpoint of integrating the datasource as a submodule, but hopefully it demonstrates that I'm trying to be a responsible maintainer.

@drunken_monkey's pull request is still outstanding and someone else opened a new bug report on Friday that I wasn't able to debug over the weekend. I think that I should probably resolve those two issues before the merge, unless you feel that there's a pressing need to do it sooner. I imagine there isn't, but let me know if you feel otherwise. I think that I can wrap up that work by the end of the week.

Woot really excited to see this make its way as have been using the github repo + drunken_monkey's patch and have created about 10 cores linked to CKAN leveraging search api solr datasource.

I can help with the review once this gets merged.

If possible if can mention any additional changes on top of what was in dev + drunken_monkeys patch.

I considered creating a new backend. I rejected the idea back in the Spring because doing so required me to override some very long and complicated methods from the default Solr backend just to make minor changes to functionality. I believed that a lot of technical debt would be incurred, requiring me to keep large amounts of code up to date with changes in the base class. I think SearchApiSolrBackend::search() was the method causing the most concern. Ultimately, I didn't implement alter hooks because they were the easier thing to do or because I'm stuck in our procedural code past; I did it to prevent future problems.

I haven't looked at the Solr backend class in a while, so I don't know if those classes have be refactored with smaller methods. I'll check it out and see if the situation has changed. If not, perhaps I could propose changes that would make it easier for me to override the code that has to be altered to make it possible to get results from non-search-api indexes.

@mkalkbrenner: I know. I looked at those too. Extending the backend meant adding an extra setup step - picking the right backend to use. I thought it might be more usable if I just implemented the hooks. I'll admit it could be a minor concern, but that was the reason for my choice.

Fair enough. I'm going to take a look at it this evening.

Wow, thank you! This is a big day for me. I appreciate the support that you and @drunken monkey have given to this project.

Do you mean that you want me to add documentation to the project docs?

Yeah, you're right. I have a little spare time this morning. I'll do that now.