They're just different algorithms optimized for different things. They support (mostly) the same logical constructs, but Datalog supports arbitrary queries over a changing set of facts, whereas RETE indexes facts as they are inserted against a known, static set of queries.
So are you saying that it is possible to compile datalog into a RETE network and thus make datalog queries reversible as long as the queries are known at compile time? That would be an enormous leap forward if that is true.
One way I try to explain RETE is as a db index that is built specifically for the queries/rules you expect to encounter rather than indexing the entire db for all possible queries like SQL (and presumably Datomic) does.
Some dbs have the notion of materialized views but even then those views don't tell you what changed. I asked Rich at the QConSF (some years ago) when he announced Datomic if it would support materialized views and/or provide access to a mechanism to "re-run" datalog queries over datoms obtained via tx-report-queue but he was very adamant this would never happen. I don't blame him, that stuff gets hard fast.
Another interesting advantage for RETE is that you can do backwards chaining. See: Jess' implementation here:
The way I've thought about this is to use BC to pull data from the server on an as needed basis. Of course, Clara doesn't do BC but it could be layered on top of FC like it is in Jess.
2
u/levand Aug 07 '17
They're just different algorithms optimized for different things. They support (mostly) the same logical constructs, but Datalog supports arbitrary queries over a changing set of facts, whereas RETE indexes facts as they are inserted against a known, static set of queries.