Added a Lark to Django Query converter

[tachyontraveler]

Additions:

• Query converter
• A few tests for the same

[codecov]

Codecov Report

Merging #61 into master will increase coverage by 1.56%.
The diff coverage is 92.85%.

@@            Coverage Diff            @@
##           master     #61      +/-   ##
=========================================
+ Coverage   76.73%   78.3%   +1.56%     
=========================================
  Files          19      21       +2     
  Lines         649     719      +70     
=========================================
+ Hits          498     563      +65     
- Misses        151     156       +5

Impacted Files	Coverage Δ
optimade/filtertransformers/tests/test_django.py	100% <100%> (ø)
optimade/filtertransformers/django.py	91.37% <91.37%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ec204b0...47e9846. Read the comment docs.

[ml-evs]

Thanks for this @tachyontraveler , looks really useful.

Not a Django person, so happy to defer to you, but is there a reason we can't have the same interface as in MongoTransformer (which inherits from lark.Transformer), with basically the same tests? I can't immediately tell that they both have the same functionality at the moment (though I'm sure they do).

Would you also be able to run these through black if they haven't been already?

[tachyontraveler]

Thanks for the comments and suggestions, @ml-evs .
I ran the scripts by black and committed those changes to this pull request.

About the Django transformer:
The Django's querying interface with SQL DBs is significantly different from that of MongoDB. So for the practical implementation of these complex queries, it is needed to use a set of django.db.models.Q class objects added together. As far as I know, Lark.Transformer is an excellent class to make string-type query combinations, but making a queryset based on an external class is either impossible as of now, or not so straightforward to my knowledge.
Because of the same reason, it wouldn't be possible to use the same unittest scripts to check the functionality of django.py script. I can confirm the reliance of these scripts since we've already implemented it successfully within OQMD database (to be released for public very soon). That said, I'd highly appreciate any further concerns or suggestions to improve these scripts at this point.

I used the non-generic keywords like band_gap and natoms on unittests since it's an example transformer to help anyone interested to quickly implement these scripts (specifying the connections of these keywords to their custom SQL DBs is an important part - as shown in the script)

[ml-evs]

Hey @tachyontraveler , thanks for the details, I thought that might be the case. This is clearly useful for anyone using Django, so I'm happy to accept.

Adding some docstrings would be nice but understand time pressures, and don't want to hold you to a higher standard than the mongo equivalent!

[tachyontraveler]

Great, thank for the review. I can definitely add the docstring sometime later.