Package proposal: Searcher

[Krzysiek Gzocha]

Hello,

I'd like to propose my Searcher library and it's integration with Symfony framework - Searcher Bundle - to PHP League.

Searcher is a framework-agnostic search query builder. Search queries are written using criteria and can be run against MySQL, MongoDB, ElasticSearch, files or whatever else you like. Supported PHP versions: >=5.4, 7 and HHVM.

 

It's main target is to split complex searching criteria into multiple smaller classes, that are easy to test and have meaningful names, so instead of long methods with complex logic, we just need several criteria, criteria builders and correct context (Doctrine ORM, ElasticSearch, Symfony's Finder or your own) for the search, but also allows users to combine different searches processes (even with different contexts) into just one search, so developer can search for something in the ORM, then pass the results as a criteria to ElasticSearch, then pass the results as a criteria to any other context and at the end return all of the results.

Searcher bundle is providing mainly configuration of searcher's via `.yaml` files, so all of the crucial services are easily accessible from the DI container and the hydration of criteria collection via Symfony's Form component.

All of the features are described in the documentation.

I'm not familiar with any similar package.

Thanks for your time!

Krzysztof Gzocha

[Woody Gilk]

I noticed Searcher when it was posted to r/php and was really
impressed. I think League should definitely consider taking on this
package!
--
Woody Gilk
http://about.me/shadowhand

> --
> You received this message because you are subscribed to the Google Groups
> "thephpleague" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to thephpleague...@googlegroups.com.
> To post to this group, send email to thephp...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/thephpleague/ea97e6e7-7e93-48ef-a220-56c611c92af4%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Barry vd. Heuvel]

Hey,

This does seem interesting, although it does seem mainly focussed on Symfony/Doctrine now. (But other frameworks could be contributed by other developers of course). I could consider looking for a basic Laravel (Eloquent ORM) implementation if I need this. As I understand it, I could chain for example Eloquent ORM filters where possible, and create a context for the Collection class, to run some filters after getting the first set or results? (Could be useful for relations or mutated values by the Model)

Looking into other League packages, I could imagine this could create a search/filter for Flysystem (per this issue; https://github.com/thephpleague/flysystem/issues/503) which could work for both Finder and Flysystem similarly (and perhaps even plain PHP). 

What I'm kind of missing after reading the docs / scanning the code, is the actual CriteriaBuilders. Now it seems to leave up most of the 'boilerplate' code for the CriteriaBuilder up to developer. I kind of expected this to be there, but couldn't find it (might have missed that however). You do have a couple of Criteria, but they are not yet implemented. I understand it's not that hard to do yourself, but isn't the DateTimeCriteria always implemented the same when using Doctrine ORM (for example)? 

Imho it would be really useful for the 'bigger' audience, when each Criteria has a matching CriteriaBuilder for the supported SearchContexts.

That way, a benefit for this library wouldn't just be abstraction and organisation of the criteria, but also providing efficient/easy usage for more complex search filters (like the CoordinatesCriteria). 

Nice work :)

Barry

Op zondag 10 juli 2016 22:24:52 UTC+2 schreef Woody Gilk:

[Barry vd. Heuvel]

Well, it wouldn't change except for the table and property, which now aren't passed to the Criteria. Although the table could be given to the Search context (?) , the property names would be a bit different then the current example. Is it currently needed to create a new Criteria for every column you search for, instead of reusing the same classes?

[Krzysiek Gzocha]

Hi!

First of all thanks for the feedback. I really appreciate.

I will try to answer all the questions.

1. "It does seem mainly focussed on Symfony/Doctrine" - if by "focussed" you mean, that there are already implemented contexts for Doctrine ORM, ODM and Elastica then you are right (thats because I was working with those contexts), but we could add more and more contexts in the future as you said. There is a bundle for Symfony, but I've picked Symfony just because I had some experience with it. We could easily create module for Zend for example and other frameworks. Framework modules could create services with proper names, maybe some validation and CriteriaCollection hydration and it would already help some people to get started with Searcher.

2. "As I understand it, I could chain for example Eloquent ORM filters where possible" - well.. I think you are referring to searcher chain, if so then it works a bit differently. By using this you can pass results from first searcher to second one (after proper transformation), when first searcher can use MySQL and other can search for Files. At the end it will return collection of both results. Both searchers in this scenario could have different criteria and criteria builders.

3. "I could imagine this could create a search/filter for Flysystem" - it would be cool to implement some context to work with Flysystem. If flysystem is using Finder then it's already done. I do not know about other adapters for files, but I would like to have one context for all Flysystem's adapters.

4. "It seems to leave up most of the 'boilerplate' code for the CriteriaBuilder up to developer" - this is exactly the idea of searcher. CriteriaBuilders will be created for each Criteria by developer by himself. I do not want to create any assumptions about how to construct query for criteria that holds some values - developer needs to do it and it is not that big amount of work that he needs to do.

5. "Is it currently needed to create a new Criteria for every column you search for,  instead of reusing the same classes?" - Simple answer: no, it is not needed. You can create for example IntegerRangeCriteria and use it in different searchers and different criteria builders.

Maybe I wrote it hard to understand way, so I will try to explain briefly how searcher works:

1. We have some criteria. Either already implemented in the library (for simpler searches) or implemented by developer (like PeopleBirthdayRangeCriteria). Criteria itself is not connected to any entity in any way and it can have just 1 or multiple fields - it doesn't matter how complicated it is. What matters is, that CriteriaBuilder can make it.

2. We have some criteria builders - those are services which are constructing the query based on given criteria. Criteria builder for PeopleBirthdayRangeCriteria would use both parameters from PeopleBirthdayRangeCriteria to construct proper query, which will return people who have birthday inside range specified in the criteria. Builder is also making a decision which criteria it supports. It doesn't need to support just one criteria, and one criteria does not need to be consumed by just 1 builder. Besides using criteria, builders have also access to SearchingContext.

3. Searching context is service with responsibility of storing "QueryBuilder" (it might be Doctrine's QueryBuilder, Finder, Elastica or whatever else) and it knows how to fetch results from it.

4. At last we are passing everything to searcher class and we are getting our results :)

In here you can see complete example.

I hope I've answered all of question. If you have more, please, feel free to ask.

Krzysztof Gzocha

[Krzysiek Gzocha]

Hey.

I know you guys are busy, but it's been almost 2 months of inactivity and no answers.

Does it mean that my proposal was refused?

Thanks for your time,

Krzysztof Gzocha

[Barry vd. Heuvel]

Sorry, I didn't really have a use-case for this so didn't actually use this. To me it feels a bit to verbose to make simple queries (but then again, I'm a simple Eloquent ORM query builder fan..)

Op zondag 7 augustus 2016 09:44:54 UTC+2 schreef Krzysiek Gzocha:

[Krzysiek Gzocha]

Hi.

I totally understand. There is no sense in using Searcher in simple examples.

I'm using it when I need to cover searching forms with multiple (20+), dynamic fields and make sure that each field is adding proper conditions.

Krzysztof Gzocha

[Krzysiek Gzocha]

... and by Searcher will provide solution to split complex query into several smaller classes with simple (for example) Eloquent ORM conditions :)

[Ben Corlett]

I actually think it is really cool and personally I'd like to invite the leadership group to consider casting a vote for acceptance?

Ben Corlett

Director

Sent from my iPhone

Please excuse my brevity

--

You received this message because you are subscribed to the Google Groups "thephpleague" group.
To unsubscribe from this group and stop receiving emails from it, send an email to thephpleague...@googlegroups.com.
To post to this group, send email to thephp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/thephpleague/a48cdb9c-1f46-4082-9c62-a6e690494176%40googlegroups.com.

[Márk Sági-Kazár]

Hi there,

I am not trying to block this from getting into the League, just posting a library with touchpoints: https://github.com/webmozart/expression#expression-transformation

This library is a generic expression builder with the possibility to transform the expression to any platform specific queries.

Not saying it's a better way, not even sure if this library should work like that.

Maybe searcher could integrate a few ideas or the whole library if it makes sense.

Regards,
Mark

[Krzysiek Gzocha]

Hi.

Searcher implements something similar to specification pattern, but not completely.

Similarities between Searcher and Expression would definitely be domain expressions and transformations.

Searcher forces user to split complex query into smaller conditions (CriteriaBuilders), so they are meaningful and easily testable, but each of them (for now) is SearchingContext specific, so it is used just with Doctrine ORM, or just with MongoDB, or just with Finder, etc, but it doesn't mean that Searcher can not make use of Expression inside and then single CriteriaBuilder could work with multiple SearchingContext's and still single builder will have simple logic inside. I would need to dive deeper inside this library to figure out more differences.

Thanks for the info, Mark.

Regards,

Krzysztof Gzocha

[Woody Gilk]

Expression is interesting, thanks for sharing! Personally I find the
Searcher much more usable and Expression a bit over engineered. (I
also don't love the use of static methods everywhere.)

I am very much in favor of Searcher being accepted as it fills a very
real need for having better value objects when using the Repository
pattern.

--
Woody Gilk
http://about.me/shadowhand

> --
> You received this message because you are subscribed to the Google Groups
> "thephpleague" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to thephpleague...@googlegroups.com.
> To post to this group, send email to thephp...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/thephpleague/82eb1816-4b8e-4b24-9b97-2020e34b83ef%40googlegroups.com.