Add support for full conditional logic in the find_by and delete_by functions. about sumo_db

[AxisOfEval]

How about this?

sumo:find_by(doc_name, [{first_name, "John"}, {last_name, "Doe"}] -> John AND Doe
sumo:find_by(doc_name, [{first_name, ["John", "Jane"]}] -> John OR Jane
sumo:find_by(doc_name, [{first_name, ["John", "Jane"]}, {last_name, "Doe"}] -> (John OR Jane) AND Doe
sumo:find_by(doc_name, [[{first_name, "John"]}, {last_name, "Doe"}]] -> John OR Doe

Rule being terms inside a list are ORed. Everything else is ANDed. Guess putting the atom 'or' inside the list might be superfluous.

[elbrujohalcon]

It might be superflous, but it makes it clearer for the reader. In your example, I would rather turn {first_name, ["John", "Jane"]} into first_name IN ("John", "Jane") but I think that's out of the scope of this particular issue. Maybe it's something good to add in a subsequent issue once this one is implemented.

[elbrujohalcon]

I want to be a little more detailed on your examples and compare them with the original proposal… Let's see…

John AND Doe

Expected query

SELECT * FROM doc_name WHERE first_name = "John" AND last_name = "Doe"

Code

% Original
sumo:find_by(doc_name, [{first_name, "John"}, {last_name, "Doe"}])
% New Proposal
sumo:find_by(doc_name, [{first_name, "John"}, {last_name, "Doe"}])

John OR Jane

Expected query

SELECT * FROM doc_name WHERE first_name = "John" OR first_name = "Jane"

Code

% Original
sumo:find_by(doc_name, [{{first_name, "John"}, 'or', {first_name, "Jane"}}]).
% New
sumo:find_by(doc_name, [{first_name, ["John", "Jane"]}]).

(John OR Jane) AND Doe

Expected query

SELECT *
   FROM doc_name
 WHERE (first_name = "John" OR first_name = "Jane")
   AND last_name = "Doe"

Code

% Original
sumo:find_by(doc_name, [{{first_name, "John"}, 'or', {first_name, "Jane"}}, {last_name, "Doe"}]).
% New
sumo:find_by(doc_name, [{first_name, ["John", "Jane"]}, {last_name, "Doe"}])

John OR Doe

Expected query

SELECT * FROM doc_name WHERE first_name = "John" OR last_name = "Doe"

Code

% Original
sumo:find_by(doc_name, [{{first_name, "John"}, 'or', {last_name, "Doe"}}]).
% New
sumo:find_by(doc_name, [[{first_name, "John"]}, {last_name, "Doe"}]]).

((John OR Jane) AND Doe) OR (Jack AND Smith)

Expected query

SELECT *
   FROM doc_name
 WHERE ((first_name = "John" OR first_name = "Jane") AND last_name = "Doe")
    OR (first_name = "Jack" AND last_name = "Smith")

Code

% Original
sumo:find_by(
  doc_name,
  [ { [ {{first_name, "John"}, 'or', {first_name, "Jane"}}, {last_name, "Doe"}]
    , 'or'
    , [ {fist_name, "Jack"}, {last_name, "Smith"}]
    }
  ]).
% New
… ??? …

I'm not sure how you would write the code for my new example above.

And we're not even adding a key component here: {'not', …}

In the end, I don't know about you, but I find the original way clearer to read. Not to mention that differentiating ["John", "Jane"] from "John" can be tricky (specially when you want stuff like day = 12 OR day = 15 that would end up in some sort of [{day, [12, 15]}].
I would not mind too much to make the 'or' atom optional (so that, if you use a tuple it's an or and if you use a list it's an and) and then we will need to figure out how to implement not logic.

[AxisOfEval]

Oh yes it does. :) I missed that all of the conditional logic is required.
Maybe not now, but later.

Just for thinking aloud, how about using prefix notation in a tuple? Like
that we can incorporate representation of all logic, including IN and NOT
using the same syntax...

[elbrujohalcon]

You mean like {'or', […]} or {'not', […]}.
I don't hate it, but I like it better when the atom(s) is/are in the place where they should be read.

[elbrujohalcon]

I'm open for opinions, of course… maybe @marcelog, @igaray, @jfacorro, @Euen or somebody else have something to say about it.

[AxisOfEval]

The reason I mentioned pre-fix is because it is easier to parse. One head operation and bam - you immediately know what has to be done with the rest of the arguments and build the query. In other methods (including in fix) you'll have to scan for tokens.

Well, yes the readability is low, but one gets used to it. And by experience one doesn't change SQL queries or such finders too frequently anyway.

Also a much better option is to use some kind of language integrated query. More here. The good news? Ecto, an Elixir project similar to sumo_db already has it implemented. Maybe we can just use that instead... More on ecto's query syntax here.

[elbrujohalcon]

oh, no… I escaped from that .NET world a long time ago 😨
In Erlang, parsing is a matter of pattern-matching and these 2 patterns are, well, equally easy to match:

parse_query({First, 'or', Second}) -> [parse_query(First), " OR ", parse_query(Second)];
parse_query({'or', First, Second}) -> [parse_query(First), " OR ", parse_query(Second)];
…

So we can include both with no real effort. We can also include a third one, if we want:

parse_query({'or', Queries}) ->
  string:join([parse_query(Query) || Query <- Queries], " OR ");

[AxisOfEval]

👍 Sounds like a plan to me :)

[AxisOfEval]

Hey, by scanning for tokens I actually meant positional pattern matching isn't always easy to infer when there's varying arguments. For example, what does one do when when has to OR three terms... Won't the function signature of parse_query change?

[elbrujohalcon]

The initial recomendation would've been to use something like:

{{Query1, 'or', Query2}, 'or', Query3}

But I understand why that can be ugly… so much that everybody starts wishing for {'or', […]} to exist 😉

[AxisOfEval]

LOL! So your plan is to force people to think of only two things at the same time... Very sinister!

[jfacorro]

Based on the current discussion here's the definition of the syntax that sumo_db will support for the find_by/2 function.

-type operator() :: '<' | '>' | '==' | '=<' | '>=' | '/=' | 'like'.
-type field_name() :: atom().
-type value() :: binary() | string() | number() | 'null' | 'not_null'.

-type expression() :: 
    [expression()] 
    | {'and', [expression()]} 
    | {'or', [expression()]} 
    | {'not', expression()}
    | terminal().

-type terminal() :: 
    {field_name(), operator(), field_name()} 
    | {field_name(), operator(), value()} 
    | {field_name(), value()}.

The expression [expression()] is equivalent to {and, [expression()]} for backwards compatibility. The following is an example of how a query expression would look like using this syntax:

{or, [{and, [{count, '<', 100}, 
             {category, '=', "shoes"}]},
      {category, 'null'}
     ]
}.

[AxisOfEval]

👍