Refactor query logic to support querying of nested structures

[jcrossley3]

We enhance the Filter and Sort structs to deal with more complex LHS expressions, e.g. "table.column"->>'key', instead of just column names.

Specifically, this enables the querying of JsonBinary and Json columns.

[jcrossley3]

@ctron the compiler told me to add + use<'_> in order to define a fn that returns a closure. I'm not familiar with that syntax, and neither the error message nor google was much help.

error[E0700]: hidden type for `impl for<'a, 'b> Fn(&'a &'b (ColumnRef, sea_orm::ColumnDef)) -> bool` captures lifetime that does not appear in bounds
   --> common/src/db/query/columns.rs:134:13
    |
133 |           fn name_match(tgt: &str) -> impl Fn(&&(ColumnRef, ColumnDef)) -> bool {
    |                              ----     ----------------------------------------- opaque type defined here
    |                              |
    |                              hidden type `{closure@common/src/db/query/columns.rs:134:13: 134:23}` captures the anonymous lifetime defined here
134 | /             |(col, _)| {
135 | |                 matches!(col,
136 | |                          ColumnRef::Column(name)
137 | |                          | ColumnRef::TableColumn(_, name)
138 | |                          | ColumnRef::SchemaTableColumn(_, _, name)
139 | |                          if name.to_string().eq_ignore_ascii_case(tgt))
140 | |             }
    | |_____________^
    |
help: add a `use<...>` bound to explicitly capture `'_`
    |
133 |         fn name_match(tgt: &str) -> impl Fn(&&(ColumnRef, ColumnDef)) -> bool + use<'_> {
    |                                                                               +++++++++

If the compiler knows how to fix it, why tell me about it?!?! 😄

[jcrossley3]

Apparently, I can omit the use<> around the '_ lifetime, which I discovered after clippy complained about this:

        fn name_match<'a>(tgt: &'a str) -> impl Fn(&&(ColumnRef, ColumnDef)) -> bool + 'a {

Still curious about the use<> syntax, though.

[ctron]

That's a new thing with 1.82.0: https://blog.rust-lang.org/2024/10/17/Rust-1.82.0.html#precise-capturing-use-syntax

You can omit it, having the previous behavior. But now the language gives you another tool for more fine grained definition of what you had in the mind. The compiler trying to educate you about new stuff.

[jcrossley3]

I knew you'd know, thanks for the direct link, which answered my original question:

Note that in Rust 2024, the examples above will "just work" without needing use<..> syntax
(or any tricks). This is because in the new edition, opaque types will automatically capture 
all lifetime parameters in scope. This is a better default, and we've seen a lot of evidence 
about how this cleans up code. In Rust 2024, use<..> syntax will serve as an important way 
of opting-out of that default.

[ctron]

I think this looks good in general. I am just a bit worried we're exposing the internal JSON structure to the user. Allowing the user to specify a path to the data inside a field might: a) make it super tricky refactoring things, b) create a security problem if the user can access data that the user's not entitled to

[JimFuller-RedHat]

LGTM

[jcrossley3]

I am just a bit worried we're exposing the internal JSON structure to the user. Allowing the user to specify a path to the data inside a field might: a) make it super tricky refactoring things, b) create a security problem if the user can access data that the user's not entitled to

That's a good point about unfettered access, and I share your concern. I think I can mitigate that by providing a method on the optional Columns struct that configures which fields in the query can be used as keys in a particular json column. I'll work up a PR.