Allow for multiple search parameter definitions?

[chaunax]

Would the epilogue team be open to adding functionality which allows for multiple search params to be defined? This would allow for more flexibility in using the various operators or against different attributes. For instance, I use the model to search around a date and would like to search before and after that day.

Perhaps this.resource.search could take in either an object or an array, with the multiple option looking like this:

search: [
  {param: 'dategt', operator: '$gt', attributes: [ 'date' ]},
  {param: 'datelt', operator: '$lt', attributes: [ 'date' ]}
]

By changing up the querystring param I pass into the REST api, I would be able to "reuse" the endpoint but have more flexibility in the searches I offer.

Granted, this could complicate the search functionality if one uses multiple search params expecting epilogue to find rows matching all criteria. Maybe at a first pass, we could allow multiple search params to be defined, but only acknowledge/execute the first matching querystring variable?

If there's already a way to accomplish this, please let me know too!

[mbroadst]

by all means, if you prepare a PR that implements this with tests, and passes all existing tests, your contribution is more than welcome :)

[cusspvz]

+1

[cusspvz]

Gonna take this!

[mbroadst]

Hey so this was sort of taken care of in #141, but I do note that @karolisg omitted the operator from your spec. Should be very easy to add at this point.

[cusspvz]

I've started to write here a really nice proposal and left it open because it wasn't good yet, guess what, had an issue with my computer where I had to restart it.

Somewhere on my proposal I had in mind was something like this:

?search[name]=Jose&country=pt

search: [
  { param: [ 'search', 'name' ], operator: 'like%', attributes: [ 'first_name', 'last_name' ] },
  { param: 'country', operator: 'aas', attributes: 'country' /* would default to [ 'country' ] */ },
  { param: [ 'search', 'custom' ], operator: ( query, context ) => /* context.criteria manipulation or some other sort of async one ... */ context.continue() },
}

My whole effort was to maintain current api style so we don't create a breaking change here, support the same spec proposed by the OP, and added deep params and custom operators.

Custom operators idea came from my need to have ours included, this will turn maintenance of current ones easier and allow third-party operators. I remember now I had something about setting up search plugins and draft a documentation for them to use epilogue-search- as prefix.

[cusspvz]

Forgot to mention, if operator is a string, it would select an epilogue included operator or fire an error.

[mbroadst]

@cusspvz sounds good, I think you can easily build upon the work @karolisg started with here

[chaunax]

Finally got some time to look at this again. @karolisg's work supported my original spec, including operators. I will try and update some documentation soon, but I am closing this for now. Thanks all!