Support multiple properties with OR in single filter reference

[derSchtefan]

Details

We have the issue that a search for a single term should look up multiple properties with an OR chain. (With EF Core and SQL Server)

Suppose there is a Course Entity, and it has related Student entities via a navigation, and the properties to be looked in are the student key, their name, etc. We have to currently hard code this into the front end, so if somebody is searching in the "Student" field, we have to send students.key=*xyz|students.name=*xyz and add this to the mapper in the backend:

 var mapper = new GridifyMapper<Course>(true)
        .AddMap("students.key", task => task.StudentAssignments.Select(row => row.StudentKey))
        .AddMap("students.name", task => task.StudentAssignments.Select(row => row.StudentKeyNavigation.Name));

We would rather simply send students=*xyz, and have the backend look in multiple properties, which are all OR chained, like this:

 var mapper = new GridifyMapper<Course>(true)
        .AddMultipleMap("students",
task => task.StudentAssignments.Select(row => row.StudentKey)),
task => task.StudentAssignments.Select(row => row.StudentKeyNavigation.Name));

with AddMultipleMap taking a string, and a params[] of expressions that are chained in ORs.

We have not found a way of implementing this elegantly, we even considered parsing the filter expression, but running through the syntax tree seemed a bit extreme.

[derSchtefan]

An alternative would be to have the separate ones with .AddMap, and have .AddSpreadQuery("students", "students.key", "students.name") to have it more generic. A filter reference to students would turn into students.key OR students.name with the operation

[derSchtefan]

@alirezanet Is there any progress by chance on this? Also asking re: @max-scopp , he had reported similar interests.

[alirezanet]

Hi @derSchtefan, unfortunately not.
I’m a bit busy these days, and this is a new feature request that’s not a high priority, mainly because it can be handled quite easily on the front-end side. I’m also not sure why you feel it’s necessary on the backend — adding complexity there isn’t great for performance. In my view, it’s better to keep this logic on the front end.
That said, if you’d like to contribute a PR for this, I’ll be happy to review it.

[max-scopp]

@alirezanet Thanks for the quick reply!

I’m the frontend dev on our side, and yeah — technically we could handle this on the frontend. But part of why we really like Gridify is that it keeps things simple and flexible, which makes it easy to use across different kinds of features.

For example, in a basic student list, frontend filtering works fine — teachers can filter by name, key, etc., no problem.

But in more specific workflows, like tagging students who might need to repeat a year, we don’t want to build search logic into the frontend. In those cases, the UI just needs to say: “Let me search for a student and show their name and picture.” It shouldn't need to know how the search works — whether that’s by email, hobby, or something else — that should be up to the backend.

That’s a big part of our approach: we want the frontend to stay a light, presentational layer, not a logic-heavy client. It keeps things cleaner and easier to maintain long-term.

If you’re not against the general idea, we’d be happy to take a stab at a PR.

[alirezanet]

Hey folks, I’m looking into the issue right now and exploring the possibility of implementing it. One thing I haven’t settled on yet is the API. Let me know which option you prefer.

1:
✅ Clean and simple to use
❌ No compile-time type safety (you can pick different types here, but you’ll most likely end up with a runtime exception).

  .AddMap("students", task => new { task.Name, task.Id });

2:
✅ Compile time type checks
✅ It might be also possible to pass a merging condition like (OR, AND)
❌ Doesn't support ValueConvertors

  .AddCompositeMap("students", task => task.Name, task => task.Id);

---

If you’re not against the general idea, we’d be happy to take a stab at a PR.

Yeah, that sounds great. I’d appreciate a PR—go ahead and take a shot at it. (sorry for the late answer I forgot to reply your last comment on this issue)

[alirezanet]

Hi @max-scopp,
After reading your comment again, I thought you maybe already started looking into this so for now I assigned it to you. please let me know if you need any help or had any issues.

[derSchtefan]

Hi @alirezanet ,

I discussed this with @max-scopp , but we did not further progress due to project pressure. I had a look into the API and what I found is that the value converters can be supported by any of these ways:

  // drop the implicit params approach and make it and explicit array, which is easy since .NET 8
 // every target has the same value converter
  .AddMap("students", [task => task.Name, task => task.Id], valueConverter:...)  

  // move the optional parameters to the front, have the params at the back
 // every target has the same value converter
  .AddMap("students", valueConverterXyz => .. , task => task.Name, task => task.Id)

  // make the api a tuple array, so each map has an option to contain a value converter
 //    public IGridifyMapper<T> AddMap(string from, (Expression<Func<T, object?>> to, Func<string, object>? convertor)[] to,
 //    bool overrideIfExists = true)
  .AddMap("students", [(task => task.Name, null), (task => task.Id, conv => conv....)])

I had looked into the first option, but then did not proceed implementing it.