Implement interpreter for mikro-orm

[stalniy]

• this interpreter should be part of a new package @ucast/mikro-orm (put it in packages/mikro-orm)
• it should support the same operators as js interpreter from @ucast/js (the most complex is $elemMatch)
• it should allow to pass custom operators
• it should use createInterpreter function from @ucast/core to create interpret function
• the return value of interpret function is a query builder
• it should take initial query builder as an argument
• when it finds condition.field with dots inside it's a hint that this property may be a relation to another table. Using mikro-orm API we should be able to understand and if a field construct query for JSON field and if it's a relation add INNER JOIN + where conditions

[ujwal-setlur]

I can take a stab at this.

[stalniy]

Awesome! Let me know if you have any questions!

[stalniy]

Hi @ujwal-setlur

Do you have any news on the progress?

[ujwal-setlur]

@stalniy, unfortunately, I got busy with work, but I will definitely get to this this week..

…

--ujwal

On Jul 12, 2020, 11:45 PM -0700, Sergii Stotskyi ***@***.***>, wrote: Hi @ujwal-setlur Do you have any news on the progress? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[stalniy]

@ujwal-setlur , do you have free time for this task now?

[stalniy]

Interpreter for Objectionjs was finished and it may be a very good reference implementation for mikro orm

[Asoftyn]

Hi, I wonder if there is any progress on this?
And if I would try to do this, where would I start so I could get a better understanding of ucast? Since I am a little confused about what it does right now.

[stalniy]

Hi @Asoftyn

No any progress on this. Your help would be very useful!

[stalniy]

The best way to start is to read this https://github.com/stalniy/ucast/tree/master/packages/core

UCAST is a universal conditions translator. It allows to translate conditions from one language to another. More formally, there are 3 things:

• Parser. parses language which we want to translate into intermediate language (i.e., object structure called AST)
• Intermediate language (AST). Recursive composition of objects that represent conditions
• Interpreter. Function that interprets intermediate language (AST) in some way.

What does this allow?

@ucast/mongo contains a parser that translates MongoDB into AST. Now, we need an interpreter that can convert this AST into mikro-orm query builder

[ujwal-setlur]

Sorry folks, I got extremely busy on my day job. Any help would be appreciated. I hope to get a break at work in a couple of weeks

[stalniy]

This may sound confusing and complicated but in fact, interpreter is a simple set of functions. Take a look at @ucast/objection implementation (https://github.com/stalniy/ucast/blob/master/packages/objection/src/interpreters.ts#L11) which is similar thing for Objection.js ORM.

Let me know if you have further questions

[Asoftyn]

I had a look around and from what I understand is that mikro-orm has support for mysql, postgresql, sqlite and mongo and is using knex.
So I was thinking that an mongodb interpreter already exists and so does one for the others using objection.js with knex. So wouldn't the interpreter part already be kinda done? Could we Frankenstein something together using code from those interpreters for the mikro-orm interpreter?

Sorry if I sound stupid I'm not used to these kinda things.

[stalniy]

I thought about similar possibilities, this requires implementation of Adapter pattern that will unify interfaces of different query builders. As a result this adds additional level of abstraction, basically another query builder interface. The issue is that for some edge cases this abstraction won't work well:

• to generate raw queries. Different ORMs may use even different binding parameters.
• to wrap SQL expressions in brackets. Some supports nested query builder and others - not. So, this will make implementation of Adapter pattern for some ORMs more complicated than it should be. For example, sequelize uses objects to construct query. So, for example to implement and operator, we will need to create an instance of nested query builder, instead of merging conditions using regular Array.

Being able to implement operators for particular ORM may allow to simplify and optimize implementation for particular situation.

I'd like to start with this approach at least for now, and find out/refactor as we go

[Asoftyn]

I have been trying and looking around at the code for a few hours but i cant get my head around it. So I sadly wont be of any use since i do not quite understand it.
I wish you all good luck with this.

[stalniy]

Guys, actually yesterday I tried to implement interpreter for pure SQL. and have pretty good results. Tested it with objectionjs and it works really good.

today, I plan to try it with mikro orm and sequelize and if it works good I’ll publish it and close this issue as won’t fix

[Asoftyn]

Im not sure i understand the "as won't fix" part but good luck.

[ujwal-setlur]

I guess it means it’s generic enough to cover all the SQL ORMs?

[stalniy]

right, I believe that all ORMs in one or another way allow to combine raw sql with their query builder interface, this allows to implement conversion to SQL and use this SQL to set conditions.

[stalniy]

close in favor of #8