Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Additional API: Complex queries #39

Open
enikao opened this issue Nov 11, 2022 · 6 comments
Open

Additional API: Complex queries #39

enikao opened this issue Nov 11, 2022 · 6 comments
Labels
postponed Postponed for later discussion

Comments

@enikao
Copy link
Contributor

enikao commented Nov 11, 2022

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

@enikao
Copy link
Contributor Author

enikao commented Jul 26, 2024

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
Copy link
Contributor

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
Copy link
Contributor Author

enikao commented Jul 26, 2024

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

@dslmeinte
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
postponed Postponed for later discussion
Projects
None yet
Development

No branches or pull requests

3 participants