mfrasca

Parsing custom query language and query Ecto database

I’m rewriting a query parser I have already written in Python twice, with pyparsing/sqlalchemy, and with ply/django. I am now interested in seeing it at work within Elixir. I am VERY new to Elixir, so I’m afraid I’m not yet in the right mindset.

this is the target:

github.com

mfrasca/luke/blob/master/src/parser.yrl

Nonterminals query domain fieldname expression bterm bfactor valuelist field terms value.
Terminals number '(' ')' '.' '[' ']' where word or boolean_add boolean_mult not false true cmp_in quoted operator aggregate .
Rootsymbol query.

%query -> domain '.' fieldname operator value
%query -> domain '=' value
%query -> query '|' DEPEND
query -> terms : {terms, '$1'}.
query -> or terms : {terms, atom_or, '$2'}.
query -> domain where expression : {from, [{context, 'Elixir'}, {import, 'Elixir.Ecto.Query'}], [{in, [{context, 'Elixir'}, {import, 'Elixir.Kernel'}], [{domain, [], 'Elixir'}, '$1']}, [{where, '$3'}]]}.
domain -> word : list_to_binary(extract_value('$1')).
expression -> bterm : '$1'.
expression -> expression boolean_add bterm : {'or', [{context, 'Elixir'}, {import, 'Elixir.Kernel'}], '$1', '$3'}.
bterm -> bfactor : '$1'.
bterm -> bterm boolean_mult bfactor : {'and', [{context, 'Elixir'}, {import, 'Elixir.Kernel'}], '$1', '$3'}.
bfactor -> not bfactor : {atom_not, '$2'}.
bfactor -> '(' expression ')' : '$2'.
bfactor -> false : false.
bfactor -> true : true.
bfactor -> field operator value : {extract_value('$2'), [{context, 'Elixir'}, {import, 'Elixir.Kernel'}], ['$1', '$3']}.

This file has been truncated. show original

and this is the corresponding ply/Python code:

github.com

mfrasca/ghini/blob/master/browse/searchgrammar.py

import ply.yacc as yacc

from taxonomy.models import Taxon, Rank
from collection.models import Accession, Contact, Verification
from garden.models import Location, Plant
from taxonomy.views import TaxonList, RankList
from collection.views import AccessionList, ContactList, VerificationList
from garden.views import LocationList, PlantList

from django.db.models import F  # used where forcing field for intersection

# Get the token map from the lexer.  This is required.
from .searchlex import tokens

import logging
logger = logging.getLogger(__name__)

# a reminder
''' <DOMAIN>.<field> <op> <TERM>
    <DOMAIN> <op> <TERM>

This file has been truncated. show original

I am not sure about a large amount of issues.

when tokenizing words, I have reserved words, too. in my ply grammar, I let the user write strings quoted or unquoted, but I think I will drop this, to make things easier. or what would you suggest?

are there guidelines / better styles to follow when speaking of Terminals and Nonterminals? I would put Terminals in ALL CAPS, but what’s the impact on the code?

to make an example, is the form ‘[’ preferable to LBRACKET ?

coming from Python, I realise I have the inclination to think I’m producing an object when parsing the query string, and in the end I would evaluate the object, which would be a query. but I guess this is not the way I should think here. I would be building a data structure, which I would then feed to one or more functions (as many as the methods of my python class), defined by pattern-match.

leaving alone when we come to Ecto, where I will need to compute unions and intersections and negations of query sets… and navigating relations between tables… and implementing aggregating functions.

just as an example, these are two legal queries:
taxon where rank.id>=17 and count(verifications)>0
accession where id in [1 5 111] and count(plants.images)>0

it would be of great help getting: code contributions and reviews, reading suggestions, related GPL software sources.

21 comments

#leex

12 3480 21

2019-06-20 15:30:36 UTC

Marked As Solved

rvirding

Creator of Erlang

Some quick comments:

in Erlang or is a reserved word, hence the syntax error, so to get the atom you need to write 'or'.
the syntax [context: Eiixir, import: Kernel] is illegal so you would have to write [{context,'Elixir'},{import,'Elixir.Kernel'}] to get the corresponding structure. Erlang has very few special syntax cases like Elixir property lists.

c. ?

Post #18

Also Liked

kip

ex_cldr Core Team

Hmmmmm I think maybe @benwilson512 meant nimble_parsec. Which would be good for this project, more expressive and easier to debug than leex and yecc.

Post #3

imartinat

You should look at Filtrex, it runs ecto queries from a map of filters.
I used it in one of my project. You could also look at Forage, Mandarin + Forage - An admin tool for phoenix, it seems to be more powerful, there is no documentation but you could ask some help to the author. He answered quickly to my questions.

Post #10

kip

ex_cldr Core Team

Less code: yes, I would agree with that (I’ve done a reasonable amount of work in leex/yecc and with nimble_parsec).

Faster: Not sure I agree. Theres some strong sub-binary optiimization in nimble_parsec too, but for sure it would require proper testing of like for like to decide. Or someone more qualified in both approaches than me,

If one has been done the learning curve of leex/yecc or their even more ancient cousins then they are certainly straight forward to use (although I do find removing shift/reduce errors/warnings less than obvious sometimes).

All said, thats why hoped to indicate that if one is getting into parsing for the first time then parse combinators are more approachable and, in my opinion, easier to debug.

Post #8

kip

ex_cldr Core Team

Well my first unix was pre-System III and it’s friends lex and yacc. I think they qualify as ancient

And thanks for writing them as part of Erlang, it feels like they should belong in any build system and it’s great they are standard issue.

Post #15

rvirding

Creator of Erlang

Yes, pre-System III lex and yacc qualify as ancient

While I did implement leex, I cannot take credit for yecc. The first yecc versions were implemented by another guy at the Ericsson Computer Science Lab, Carl Wilhelm Welin.

Post #16