Fork me on GitHub
#datomic
<
2021-07-08
>
babardo14:07:27

👋 With datomic cloud, is there any way to enforce unique constraint in https://docs.datomic.com/cloud/schema/schema-reference.html#db-iscomponent entities?

(d/transact (env/get-conn)
   {:tx-data [{:operation/id "test-id"
               :operation/parameters
               [{:operation.parameter/paramete-one "one"}
                {:operation.parameter/paramete-one "one"}]}]})
With schema being [:operation/parameters :ref :many :component] and [:operation.parameter/paramete-one :string :one :unique], I can easily create duplicate parameters.

jarrodctaylor15:07:19

When you query :operation/id “test-id” after executing the transact. What value do you get back for :operation/parameters?

babardo21:07:15

(d/pull (d/db (env/get-conn)) '[*] [:operation/id "fichtre"])
=> 
{:db/id 101155069755987
 :operation/id "test-id"
 :operation/parameters
 [{:db/id 101155069755988, :operation.parameter/paramete-one "one"}
  {:db/id 101155069755989, :operation.parameter/paramete-one "one"}]}

cjsauer14:07:24

Hey all, I recently downgraded my prod system to a dev system after playing around with it for a bit. I set the solo stack’s reuse storage setting to true, and everything seemed to go smoothly, but I keep running into this error while trying to connect from my laptop via the socks proxy:

; Execution error (ExceptionInfo) at datomic.client.api.async/ares (async.clj:58).
; Loading database
I see https://docs.datomic.com/cloud/troubleshooting.html#loading-dbthat database loading errors have something to do with “not yet loaded the requested database into memory” and I should consider it retryable, but no amount of retrying seems to be working. I’ve tried temporarily scaling up my DDB capacity in case that was it, to no avail (the db barely has any data in it anyway). Any ideas what would cause this?

cjsauer14:07:02

Disregard this whole message. The KMS key I was using for the old system had been accidentally disabled. sigh

joshkh14:07:13

on a scale from tomorrow to never, will there eventually be the possibility to excise data in cloud? or is that entirely off the roadmap?

tatut08:07:11

I have no knowledge, but have been operating under the "never" assumption

ghadi18:07:52

@U0GC1C09L is your use-case for excision GDPR compliance?

steveb8n22:07:56

Id like to know this answer also. Yes for gdpr

joshkh00:07:31

@U050ECB92 yes, i'm asking in the context of GDPR. i know this conversation comes up every now and again, but i thought i'd check back because i haven't heard anything regarding cloud excision in a while. i'm in the process of making some relatively hefty architectural changes to move/store certain data outside of datomic (we considered https://medium.com/magnetcoop/gdpr-right-to-be-forgotten-vs-datomic-3d0413caf102, but i think a separate datastore is our best option). it's just a shame that we have to fight against some amazing technology, Datomic Cloud, because it doesn't meet our compliance needs

jaret02:07:36

Hi @U0GC1C09L, We completely understand the need you are facing and are reviewing options for implementing functionality that satisfies GDPR use cases. However as you know, we do not currently have a feature to support the complete removal of data in Datomic Cloud. We have seen customers use a separate data store and the throwaway keys solutions that you mentioned. In response to your "scale of tomorrow or never" roadmap question, I think its worth saying here that we do not publish a roadmap of Datomic feature development because we've made a commitment to stewarding the product according to technical best practices and we do not want the risk of customers developing against promised functionality that may turn out to be a bad idea of the product as a whole or be reprioritized in favor of more critical features. So as much as I'd love to give you a more satisfactory answer, I cant. I will share this feedback with the team and reiterate that we understand the need here and feature requests like this are taken seriously as part of product management decision-making.

jaret02:07:44

If you think there is value in it, perhaps we could arrange a call to discuss what you are working on so I can give a full report to the team or perhaps make suggestions to your chosen solution. Just let me know, or open a case with <mailto:[email protected]|[email protected]>.

jaret02:07:18

Apologies for having to fight against Datomic, but GDPR has presented a difficult use case for a DB that is built on immutability.

steveb8n07:07:02

I’m gonna end doing the same as @U0GC1C09L for customer/PII data. will probably use Crux. The risk is that Crux tempts me to move everything off of Datomic. Stating the obvious but it’s worth mentioning it when you discuss with the team.