Why Mangle (Datalog) when there is miniKanren?

[kathe]

To begin with, I am not at all qualified to understand the difference between Prolog/Datalog and miniKanren/microKanren.

But, the way I see it, with a Datalog implementation like Mangle, data (within an RDBMS) would have to be exchanged with an external application.

On the other hand, implementing a miniKanren/microKanren using a RDBMS's internal SQL PL would probably yield better performance by avoiding moving data out/in of the RDBMS.

Again, I might be severely mistaken, and would appreciate anything you all could share to help me understand the value of Mangle to engage with a relational database like CockroachDB.

[burakemir]

Hey there! Thanks for these questions. There are many approaches to logic programming. Your question mentions integration into RDBMS, so I assume you are asking about applied, practical questions.

• Translating relational programs into SQL queries and leveraging the optimized engine of an RDBMS should be considered a possibility for all logic / relational programming languages that admit a translation to SQL. I would agree that if moving data out is a concern, either due to size or due to freshness, then translating queries and sending them to a DB is the better option.

(Datalog is particularly interesting, because recursion-free datalog corresponds exactly to relational algebra and can be rendered as a SQL query. In Mangle, this is not implemented, but it could be and it is already possible today to specify "modes" to indicate that a top-down mode of evaluating a query is preferred.)

• minikanren involves a top-down search procedure, whereas a key aspect of bottom-up evaluation is that it enables the use of (database-)join algorithms. Once more, currently the Mangle implementation does nothing very fancy to implement joins, but it could be done without changes to the language.

In summary, there are many "small" problems can be solved elegantly with in-memory representations of data and logic programming (or constraint logic programming). When it comes to working with real data, it is not practical to export everything however it is often possible and practical to 1. first, query relevant data that fits in memory, 2. then, perform the in-memory evaluation. The easiest way to implement such a thing today would be to implement a FactStore which, whenever queried, actually translates the query to something a backend understands. This way, it is possible to query and combine any number of DBs, provided the queries send to those backends are specific enough that the resulting data fits into memory.

More advanced approaches to processing such as stream processing are also possible in some scenarios, but would require a bespoke approach to evaluation.

Hope this helps! Did I answer your question?

[kathe]

Yes, your response did answer my question, pretty well.

Thanks a million for taking the time for posting your response.

[sylph-eu]

Let me illustrate one such problem :) We're using google/mangle to accumulate data from multiple heterogenous sources and execute a bunch of queries to reveal interesting properties (issues or recommendations). Keeping/querying facts in-memory is very convenient as we do not need setup/maintain full-featured RDBMS and its ingestion pipelines (to keep data up-to-date). It's sufficient to pull data at runtime, populate fact store, execute queries, and throw it all away.

Please also let me use this opportunity to thank for the library itself! 👍

https://techblog.citystoragesystems.com/p/nuance-preventing-schema-migrations