mmalek06

I figured, I'll give an update to anyone who's still interested. I managed to fix a few issues and and some major functionalities (eg: * symbol to select all) over the last days. The next thing I'll work on will be type queries, so that the user will be able to use queries as strings but also as a chain of method calls with a type parameter representing the model returned from the query. Something like: from(jsonObject).where(list of filter functions).select[CaseClassType]() . Stay tuned!

As for the „why do we want it to look like sql” - I like the syntax and I think it’s much more readable than any other language used to process data. But that’s just a matter of taste :)

Please read my description (found somewhere in this discussion). That being said: there are scenarios when being able to save a query into a database or config file, then load and run it is useful. In general I agree though and that’s why one of the enhabcements I want to implement is to create a method based syntax with projecting selected fields to a case class.

Ok, maybe I got too defensive and assigned to much weight to the first part of your first sentence. No strawmanning intended :)

That looks nice. Can it be used in a program? I mean, not from cli, but inside code?

Also: please look at my first comment, from 13 hours ago - it should shed some light on the "why" part.

Still, it seems like a lot of work. My case was that I just wanted to feed JSON document into some mechanism that will give me back what I want. I wouldn't like to embed whole Spark framework into my app. I will read about it though :)

I don't agree :). SQL nicely abstracts what would have been more difficult or technical to do otherwise. Yep, it was create in order to enable non strictly technical people to query their data, but does it make it bad? I don't think so. Also authors of great many NoSql databases (and other technologies, ever heard about the widely loved LINQ technology in C#?) think, giving their users the possibility to query data using what they already know. Also: can you honestly, from the bottom of your heart, say that you'd rather filter json documents using some form of XPath? Besides: I'm not trying to criticize relational model, as well as I'm not saying that JSON is the way to go when storing data :D I just wanted to create a tool for people that are trying to implement a very specific business case I described and, due to lack of tools, are having some issues with it.

Ah, I get it - it’s an uber ORM!

OctoSQL looks very nice and I’ll check it out soon. Do you have Scala bindings for it?

Didn’t know about it. Is it possible to use only that subset of apache spark lib?

I recently published a github project with the purpose mentioned in the post's title. Obviously if you just want to parse JSON, there are much better Scala libraries, like Circe. However in my case, I had to filter responses from a very dynamic api that I couldn't change in any way (for example to give me prefiltered results). My first choice was to use JsonXPath Java lib, but I didn't like that XPath-like notation, so I figured that some people may benefit from using what most of us already know - SQL - to create them queries. In my project, it was supposed to be configurable - the architect wanted to enable the not so technical business bunch to query json documents almost without programmers help and the easiest way to do it was to put their queries into the database and them allow them to match a query against an api. I left the project some time ago, but the idea I had back them kept me awake at night and here it is. Hopefully not entirely very bad ;) If you like it, I could really appreciate some help with development of the rest of some even cooler functionalities.