Additional API: Complex queries

[enikao]

e.g. "get me all dog owners of dogs named Lassie, and resolve the owner's references to all dogs"

[enikao]

I think specifying this in a way that works with different repo implementations, and suitable for different client host languages, is a lot of work.

Some ideas for inspiration:

• C# LINQ, seems to work both for pipes / map / filter / streams and SQL
• XSLT, as a language-independent spec with similar capabilities

[dslmeinte]

Personally, I think I'd rather pursue having a functional language that's also suitable for expressing complex queries in. The reason is that many DSLs end up having a “funclarative” sub language anyway, so it's catching two birds with one stone. (In fact, C# LINQ is also pretty close to this.) Also: the perceived expressiveness of SQL/XSLT has diminishing returns for complex queries because they tend to lack the abstraction mechanisms that FPLs have.

[enikao]

How would a functional language allow efficient implementation in e.g. lionweb-repository with an SQL backend?

[dslmeinte]

How would a functional language allow efficient implementation in e.g. lionweb-repository with an SQL backend?

Should be possible by mapping the FPL directly onto SQL queries. I have some ideas, and of course no time to bring those to fruition :)

[ftomassetti]

I would lean toward starting with a solution as easy to implement as possible vs something more ambitious. The reason is that, given the limited resources available, we would risk not being able to implement the complex solutions for months (or years?), while with something simpler we may have something we can start benefit from sooner and learn from.

I would start with a very thin abstraction layer over SQL, as we will translate that query to SQL for the time being

[dslmeinte]

Neither option prohibits the other from happening, apart from in the “resources department”, i.e.: time.