I know we just migrated away from using the Google PHP library for Solr integration, however the Solarium project seems to be a very well constructed library with great APIs and thorough documentation. In addition, it has an integrated load balancer and an abstraction layer for spatial queries that make it very compelling. Even if it isn't integrated into the module, there are definitely lessons we can learn and code that could be reused. We would also have to work with the maintainer to add a dual license to the project to be GPL compatible it the maintainers of this module choose to integrate the project in.

Comments

ebeyrent’s picture

ebeyrent commented

I'm a big fan of the Solarium project, which allowed me to rip out a 10-year old custom Lucene integration and replace it with Solr in a short period of time. Solarium is very intuitive, thanks in part to the fluent interface, and has a ton of features.

pwolanin’s picture

pwolanin commented

License appears not to be an issue (2-clause BSD should be GPL compatible).

https://github.com/basdenooijer/solarium/blob/develop/COPYING

However, I am leery of going down this path, since it would require a substantial rewrite of the Drupal module. I'm not clear what we gain from that other than integrating with a standard library (good), but then we add an external dependency which was a pain point for installation previously.

ebeyrent’s picture

ebeyrent commented

The feature set alone should be enough. For example:

http://www.solarium-project.org/2012/01/suggester-query-support/
http://www.solarium-project.org/2012/01/new-solarium-plugin-parallelexec...

pwolanin’s picture

pwolanin commented
Status: Active » Closed (won't fix)

Not for Drupal 7, and likely not for Drupal 8 unless is moves to a PHP 5.3 namespace + PSR-0 autoloading.

ebeyrent’s picture

ebeyrent commented

According to the Solarium folks, it's already PSR-0 compliant. Namespaces are being worked on, and will be in the next major release. I'd love to see this for D8.

milesw’s picture

milesw commented

+1 for considering Solarium. I just used it for a small project and it was a pleasure to work with. Documentation and examples made it easy to jump right in.

damienmckenna’s picture

damienmckenna
Location TN, USA
commented
Status: Closed (won't fix) » Postponed

Lets leave this open but postponed so it can at least be discussed and more easily found.

So is the wish to not handle it in D7 just because nobody involved currently has time to deal with it?

cpliakas’s picture

cpliakas commented
Title: Explore integration with Solarium » Explore the benefits / drawbacks of integrating with the Solarium library
Category: feature » task
Status: Postponed » Active

Well, with anything you have to weigh the benefits against the effort to implement. Is it worth focusing on a major API change that only solves minor DX issues as opposed to focusing the same effort and making comparatively more progress on more important issues such as stability and usability? Being the one who posted the original issue, I very much welcome the discussion. However, there is no analysis in this thread other than people saying it is a well documented library and great to work with. Therefore there is no compelling reason to move forward.

Call to action... find the limitations of the current API, illustrate how Solarium would solve the pain, be honest about the limitations and drawbacks of Solarium, and propose a plan on how to proceed. Changing to an active discussion task, but without any of that information there is no reason to keep this issue open.

Thanks,
Chris

pwolanin’s picture

pwolanin commented

solarium requires and uses curl directly. In D8 we'll likely use guzzle or something with that sort of interface, so I'm pretty sure this is a "won't fix".

Crell’s picture

Crell commented

pwolanin: Uh. That argument makes no sense to me. One third party library *doesn't* use another third party library, so we'd refuse to use it? Why?

pwolanin’s picture

pwolanin commented

@crell. Yes, absolutely. Because we'd then have to hack into it to change the http behaviors.

Why would I pull in an external lib bloated with a lot of curl code that we already have in core? Also, we need a clearer philosophy about external libs I think - you don't want to use them like a n00b site builder installing Drupal module until they get to 200 just becuase they think each one adds a little something they don't have to build.

my past review of this one didn't actually lead me to think it was much better than what we already have for most use cases, and it would require an overhall that would delay the D8 upgrade by ~3-6 months.

cpliakas’s picture

cpliakas commented

Solarium requires and uses curl directly

That's not entirely true. The client has pluggable adapters, and I believe the default HTTP adapter uses curl. There is also a PECL adapter and Zend adapter, and it is pretty easy to implement a custom adapter using whatever system Drupal is using. Yes it would still have to be written, however curl is defintely not a requirement.

pwolanin’s picture

pwolanin commented

ok, well the exciting features mentioned above at least partly center around cURL.

I've not seen any convincing ROI argument for the work and risk involved - converting our existing code to use PSR-0 should be < 1 day

Sometimes code shouldn't be overly flexible - that become a real maintenance burden since we wouldn't be testing with all the possible back-ends.

giorgio79’s picture

giorgio79 commented

Looks like Chris started some coding here http://drupal.org/sandbox/cpliakas/1899634

This stuff looks awesome: http://www.solarium-project.org/2012/12/solarium-3-0-0-released/

nick_vh’s picture

nick_vh
he/him
Location Ghent
commented
Status: Active » Fixed

Woa, seems he had some fun creating it! Once Solarium moves completely to Symphony we should certainly consider it as a possible viable option. I read "Code style switched from Zend Framework 1 to Symfony 2 (but Solarium is still not tied to a framework!)" so I'm not sure if that is a good of a bad thing :)

cpliakas’s picture

cpliakas commented
Status: Fixed » Active

Code style switched from Zend Framework 1 to Symfony 2 (but Solarium is still not tied to a framework!)" so I'm not sure if that is a good of a bad thing :)

I don't really think it matters. It adheres to PSR-0, which is the important thing. This statement simply means that it adopted Symfony's coding standards, which is largely unimportant. The important part is that is works across frameworks.

Re the module, it is a proof of concept to actually see what Solarium can give us. How much code can it eliminate? Are there other PHP projects that can also be integrated with to enhance the capabilities of this module? Are there things that we have said aren't possible that really are possible if we think about them differently? Are we missing an opportunity to be part of the PHP community at large?

Switching status back to "active" since the sandbox project is separate and not tied to this project. The benefits / drawbacks are not yet vetted, and it is still unclear whether the Apache Solr Search Integration maintainers are willing to make this architectural change.

giorgio79’s picture

giorgio79 commented

Re the module, it is a proof of concept to actually see what Solarium can give us. How much code can it eliminate?

For my part I have been tearing my hair out trying to get some Distance Facets going, but gave up recently since location support at the moment is in baby shoes both in Search API and Apache Solr Search. Solarium has geospatial support that is lightyears ahead. Literally a dream come true. :)

Check this out!
http://wiki.solarium-project.org/index.php/V3:Geospatial_support

and a concrete code example
http://wiki.solarium-project.org/index.php/V3:Query_helper

ebeyrent’s picture

ebeyrent commented

One thing I particularly appreciate is the support for multiple endpoints. I want to be able to index content to the master, but be able to search using the slave.

nick_vh’s picture

nick_vh
he/him
Location Ghent
commented

In which way does the solarium achieve this? Afaik you can't send a query to a slave or master and tell Solr he really wants it from the master? In our case we have a load balancer in front of the master and slave that chooses for the user.

ebeyrent’s picture

ebeyrent commented

Solarium supports multiple endpoints. You set one endpoint to be the master, and designate that as the index endpoint. The other endpoint points directly to the slave, and you use that one for queries.

cpliakas’s picture

cpliakas commented

@Nick_vh,

Effectively Solarium has the option for the PHP app to become the load balancer. Although many people elect to use Nginx for routing reads to slaves, it has the opportunity to eliminate that hardware requirement under certain circumstances. Check out the Loadbalancing plugin overview.

Interestingly enough, right under it is a PostBigRequest plugin which is something that we have been struggling with here. We did solve it, but Solarium actually solved it first. Just more food for thought.

Chris

pwolanin’s picture

pwolanin commented

The old PHP library also has such a PHP load-balance app.

imho - this is not a very robust solution or easy to explain to people, so in general I have avoided adding any support in the module for it.