How do you handle more complicated relationships with filters?

[joeshaw]

Hi Ben,

I am working on a project that uses SQL and I landed on a design that's pretty similar to this project's, but one thing I am struggling with a bit is how to handle more complex filters using the FooFilter design. Rather than filtering on strict equality, my project has to do a lot of greater than/less than checks (with the occasional null check as well). Modeling this is a bit annoying... I could have something like:

type FooFilter struct {
    PriceGreaterThan *int
    PlacedOnSaleBefore *time.Time
}

but it feels awkward to encode those in Go structs, even if I don't really need them to be general (ie, I probably will never need PriceLessThan).

I'm curious if you have any suggestions for how to deal with this that still maintains the separation of the "service" layer from the SQL layer.

[benbjohnson]

Hi Joe,

I agree it feels a bit awkward but I haven't found a better way of doing it personally. You could build some kind of Expr type that has EQ/LT/GT/etc but that sounds overly complicated for this kind of thing.

Ben

[joeshaw]

Yep, I started down that path and it was a lot of annoying code for very little value. Also difficult to maintain the layer separation without a bunch of type switches in the SQL layer.

Oh well, I'll let you know if I come up with anything better.

[joeshaw]

If you wanted the exciting conclusion to this, as I've done further development I've found that the number of ways I need to query and update are pretty limited and the generic route isn't especially worth the added complexity. So instead of:

func GetFoos(ctx context.Context, filter FooFilter) (*[]Foo, error)
func UpdateFoo(ctx context.Context, id string, upd FilterUpdate, filter FooFilter) (*Foo, error)

I've defined specific methods:

func GetFoosPricedAbove(ctx context.Context, price int) (*[]Foo, error)
func GetFoosOnSaleBefore(ctx context.Context, when time.Time) (*[]Foo, error)
func UpdateFooPrice(ctx context.Context, id string, price int) (*Foo, error)

which seem fine given my limited number of operations.

[benbjohnson]

That seems reasonable if you have a limited number of endpoints and you don't need to provide generic search to end users. 👍