Binary Large OBject

;)

As opposed to a Character Large OBject (CLOB)

lol you KNOW they came up with that after "blob"

When I upsert a unique/identity attribute, what’s removed exactly? Is the existing entity identifiable by that attribute-value combination removed? i.e. Insert [[1 :unique-attr “foo”] … bunch of other attributes associated with 1]. Insert [2 :unique-attr “foo”]. Are all attributes associated with 1 removed, or just [1 :unique-attr “foo”]?

@alex-dixon nothing is removed? I may be misunderstanding you

Maybe you can show us a sample transaction?

Thanks. So I don’t have one unfortunately but could try to create one. I’m really just not clear on the basics of what ends up happening when I transact an attribute that is marked :db.unique/identity and I haven’t been able to find an answer. I’ll try again! E.g., if :username is :unique/identity, and I transact [eid2 :username “foo”] when [eid1 :username “foo”] is already in the db, does Datomic remove everything associated with eid1?

@favila

If eid2 is not a tempid and is different from eid1, you will get an error

Datomic never silently retracts anything

If eid2 IS a tempid, the tempid will resolve to same eid1, and you will assert on the same entity

Ah. Ok. Yes I should have specified it wouldn’t be a temp id. I guess I’m interested in the behavior of both

Ohhh

That is the special behavior of upsetting

*upserting

Ok. Thank you. That’s a huge help

A simple unique (vs identity) will error out in that case too

So db unique identity affects tempid resolution, fundamentally

So if I wanted that behavior, would I just write a database function?

What behavior?

Sorry. If I wanted to remove everything about e.g. a “user” entity when I remove :username, or some arbitrary attribute for the entity

You mean db.fn/retractEntity?

Yyyes. Kind of. Like I would want to basically declare “nothing about a user exists if ever there is a user without a username”

I know there’s component but don’t see how it could be used at that level (within an entity)

The invariant you describe is not enforceable by datomic alone

Datomic only keeps attr level invariants

Ah hah. Ok. I’ve had that impression

So you need a distinct "delete user" op that your app always goes through

You can't have [[:db/retract eid :username "foo"]] automatically result in all eid being retracted

Ok. I thought about whether that behavior could be emulated by having :user, then all attributes associated to that (:username, etc). Then if I retract :user and the attributes are components…

If your notion of delete user is merely "ensure there are no references to this rid in the db anymore" db.fn/retractEntity is enough

But sometimes other types become invalid by the loss of their reference. You need to know what those are and deal with it

E.g. If you had a user-prefs entity with a required user reference attr, and you del the user, what should happen to this entity?

Should you error? (Force deleting the user prefs explicitly) shouldnyou transitively delete it automatically? Etc

So any entity or cross-entity invariants are your responsibility

Ok. Thank you so much. That makes a lot of sense. It seems like Datomic itself will never put me in the situation if I program correctly. Unfortunately I’m working on a framework (borrowing partially on ideas in Datomic) where I think I’ve introduced this problem as part of the implementation 😅

Seems like a situation where an error very much should be raised

Transaction fns corresponding to your "operations" can help you, both organizing your code and keeping always in sync with data, and removing possible race conditions

But you face same advantages and disadvantages as db-level triggers in a traditional sql db

Nevertheless it’s tempting to have something like an “essential property” for an entity…otherwise it seems the maintenance surrounding such a case falls to users

(Except you also have full history)

There are some libs out there that try to do some entity-level enforcement

There's also a talk about structuring datomic attribute schema such that entity and type invariants in a db are self-describing

(Meaning you could potentially use a smaller handful of generic tx fns for CRUD ops)

But most of the time you want an app layer on top of datomic anyway. E.g. A rest interface

At the very least is for authorization checks

Sorry I am on a phone and am autocorrecting hard

Makes sense. And interesting, thought I was encountering something isolated but sounds like other libs are trying to solve related issues?

Lol. Honestly just grateful for the responses. Thanks again

Yes sure. However your life will be easier if you shed as many entity level invariants as possible

ERD style design (e.g. For a relational db) tends to produce closed types with rigid entity invariants

You can be more open in a graph style db

Use namespaces on attrs to resolve ambiguity. Express reference attr invariants in terms of required attrs on the destination entity instead of on a strict entity "type"