alex-dixon
commented
7 years ago After a discussion with Francis Avila on Slack I was able to confirm that Datomic has no support for something like an "essential property" for an entity. Such problems are in the hands of the developer, not the database or the API.
I don't think it makes sense for us to introduce this behavior without also introducing the concept of an essential attribute explicitly. In other words, we shouldn't by default retract everything for an entity when :unique/identity attributes clash, or even upsert in the case where [1 :username "foo"] exists and we insert [2 :username "foo"] and :username is :unique/identity. Both seem to tend toward unexpected behavior.
Instead of this we plan to surface an error through rules that informs developers of the conflict and allows them to resolve it. See #51 for implementation details.
This seems a good feature to add in the todomvc example.
In todomvc, we enforce unique titles. However, because a todo is created with other attributes (:done, :visible), those facts end up being inserted, so we can end up with the following:
"Entities" [{:db/id #uuid "4ac207db-9175-4334-818b-a42ea9967ad5", :todo/done false, :todo/visible :tag} {:db/id #uuid "458162a9-ba9c-4778-a8a8-e6f73087c82a", :todo/title "abcd", :todo/done false, :todo/visible :tag}]
The blank todo shows in this case because an additional todo with a title of "abcd" had been added, then removed because it is a unique attribute, leaving behind :done and :visible. :visible is used to detect what todos should be shown.
Logging the issue as a bug for now since it could be worked around at the application level. It's definitely something we want to help users deal with at the API level. Will brainstorm options later. One that comes to mind is a "component" designation from Datomic though I don't think it's an exact fit for this case.