(tx) Implement :db/retractEntity. (#378) #223

New issue

Open

opened 2020-08-06 16:56:55 +00:00 by gburd · 0 comments

gburd commented

2020-08-06 16:56:55 +00:00

(Migrated from github.com)

Datomic used to expose :db.fn/retractEntity and
:db.fn/retractAttribute, but there latest Cloud offering has only
:db/retractEntity. Since that's what I am interested in using, that's
all I've implemented.

This transformation doesn't follow the existing pattern of inserting
into the temp.*_searches table. It instead populates
temp.search_results directly from datoms, and in so doing it makes
some assumptions about how the searches tables will be accessed.

It might be even more efficient to have an entirely new temporary
table just for these retractions. One advantage with the current
scheme is that indexing restrictions placed on the search results
table will apply to the datoms retracted by :db/retractEntity as well.

There are a few remaining items TODO.

TODO: ensure that we mark the schema as potentially modified when we
:db/retractEntity. It's not clear to me how to do this efficiently.

TODO: ensure that transaction watchers get the correct transacted
datom stream. I didn't try to address this yet because it appears to
me that the existing watcher implementation isn't quite correct: it
tells watchers about datoms that are potentially to be transacted but
not about datoms that actually are transacted. This, of course,
matters when watching :db/retractEntity entities being transacted.

Datomic used to expose `:db.fn/retractEntity` and `:db.fn/retractAttribute`, but there latest Cloud offering has only :db/retractEntity. Since that's what I am interested in using, that's all I've implemented. This transformation doesn't follow the existing pattern of inserting into the temp.*_searches table. It instead populates temp.search_results directly from datoms, and in so doing it makes some assumptions about how the searches tables will be accessed. It might be even more efficient to have an entirely new temporary table just for these retractions. One advantage with the current scheme is that indexing restrictions placed on the search results table will apply to the datoms retracted by :db/retractEntity as well. There are a few remaining items TODO. TODO: ensure that we mark the schema as potentially modified when we :db/retractEntity. It's not clear to me how to do this efficiently. TODO: ensure that transaction watchers get the correct transacted datom stream. I didn't try to address this yet because it appears to me that the existing watcher implementation isn't quite correct: it tells watchers about datoms that are potentially to be transacted but not about datoms that actually are transacted. This, of course, matters when watching :db/retractEntity entities being transacted.