Fork me on GitHub
#datomic
<
2019-11-22
>
Per Weijnitz10:11:48

Does anyone know if Cognitect is still in business? The forum link is dead (https://forum.datomic.com/) and we don't get any response from their support. Our agency needs to migrate to AWS Stockholm, but Datomic Cloud is not available there (the docs says "contact support for other regions", but that seems hard).

schmee10:11:32

forum is up for me at least

👍 4
Per Weijnitz11:11:01

Ah, it's come back online, good.

👍 4
Per Weijnitz13:11:31

I have now received a response on my support ticket, so is good.

Alex Miller (Clojure team)13:11:41

Very much still in business :)

Alex Miller (Clojure team)13:11:08

The forum is a third party service and they seem to be having some issues this week

cjmurphy16:11:38

Installing an attribute is straightforward, for example you could submit this to the transactor:

{:db/ident :student/first
 :db/valueType :db.type/string
 :db/cardinality :db.cardinality/one}
How would I go about retracting the same attribute?

shaun-mahood16:11:05

@cjmurphy I don't think you can - it would cause issues with historical data in a system with data transacted to it.

cjmurphy16:11:18

But what about if that attribute was never used in any way? So all you did was that statement above, then you wanted to get back to a world where :student/first was no longer present, where you decided it was a mistake to have that attribute?

shaun-mahood16:11:33

I haven't found a way - it's only happened to me in development, so I have had to get used to forgetting that it exists until I recreate and repopulate my database (which I tend to do pretty often as I'm figuring out what attributes I want).

johnj16:11:31

@cjmurphy I haven't tried, but doesn't [:db/retract 'identifier' :db/ident :student/first] work?

cjmurphy17:11:06

What would identifier be there? Using :db/id did not work out:

Execution error (Exceptions$IllegalArgumentExceptionInfo) at datomic.error/arg (error.clj:57).
:db.error/not-an-entity Unable to resolve entity: :db/id in datom [:db/id :db/ident :student/first]

johnj19:11:12

identifier is the entity id eid of the attribute you created

johnj19:11:15

in this case it would be the natural number datomic assigned to that attribute

johnj19:11:35

schema attributes are just like domain attributes

johnj19:11:39

you can query them

cjmurphy05:11:37

Seems to have worked thanks :) I did a pull query using [:db/id] , where the eid arg usually goes I put the attribute, so would be :student/first here. I got a low number (3 digits) eid as a result. Then I plugged that into: [:db/retract eid :db/ident attribute-name] . Sending that to transact gave back the normal success result.

fjolne17:11:53

@cjmurphy This seems to be an undocumented feature, and it behaves rather weird, because (d/ident db <attr-eid>) still returns the retracted ident, while (d/touch (d/entity db <attr-eid>)) doesn’t contain the ident anymore. The installation of the attribute with this ident creates a new attribute entity though, so this kinda works, but you’re still left in a kind of inconsistent state. A more conventional (and documented) approach would be to alias the attribute entity with some new ident, and then reuse the old one: (d/transact conn [{:db/id :student/first :db/ident :student.deprecated/first}])

fjolne17:11:33

Also, there’s no need for a separate query / pull to make a retraction of the ident, as idents are interchangeable with entity ids in transactions: (d/transact conn [[:db/retract :student/first :db/ident :student/first]])

✔️ 4
cjmurphy16:11:49

Thanks @shaun-mahood yes. I can certainly see myself having a production system and putting new attributes in entities then deciding they were put in the wrong place. If there's no actual data (so no students have been put in the system in the example above), then - well it makes sense to be able to remove attributes so the schema remains clean (and identical to the yuppiechef schema that in my case is what's normally used to create attributes).

cjmurphy05:11:37

Seems to have worked thanks :) I did a pull query using [:db/id] , where the eid arg usually goes I put the attribute, so would be :student/first here. I got a low number (3 digits) eid as a result. Then I plugged that into: [:db/retract eid :db/ident attribute-name] . Sending that to transact gave back the normal success result.