This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-06-20
Channels
- # announcements (1)
- # beginners (164)
- # calva (70)
- # cider (26)
- # cljs-dev (6)
- # cljsrn (1)
- # clojars (3)
- # clojure (123)
- # clojure-berlin (1)
- # clojure-dev (5)
- # clojure-ecuador (9)
- # clojure-europe (2)
- # clojure-italy (14)
- # clojure-nl (21)
- # clojure-nlp (5)
- # clojure-portugal (1)
- # clojure-spain (3)
- # clojure-spec (26)
- # clojure-uk (47)
- # clojurescript (17)
- # clr (1)
- # code-reviews (7)
- # core-async (5)
- # cursive (8)
- # data-science (2)
- # datomic (28)
- # emacs (23)
- # events (1)
- # fulcro (43)
- # graalvm (6)
- # graphql (8)
- # immutant (5)
- # jackdaw (17)
- # jobs (1)
- # jobs-discuss (20)
- # joker (3)
- # leiningen (8)
- # luminus (12)
- # off-topic (61)
- # overtone (5)
- # pathom (2)
- # quil (1)
- # re-frame (15)
- # reagent (2)
- # reitit (23)
- # remote-jobs (1)
- # schema (1)
- # shadow-cljs (26)
- # tools-deps (56)
- # vim (4)
Frustration. I have the following query:
(def get-dev-user-q '[:find ?e :where [?e :user/email <mailto:[email protected]|[email protected]>]])) (defn mig-user-role-on-dev-user [conn] (let [devuser-id (d/q get-dev-user-q (d/db conn))] (d/transact conn {:tx-data {:db/id (ffirst devuser-id) :user/role 1}})))
Stepping back: why query at all? Either user email is unique, in which case why not mark it so and use :db/id [:user/email “whatever”], or what you are doing is unsafe because you are essentially picking a user at random that happens to have the same email
it throws this error:
Caused by: java.lang.IllegalArgumentException: Don't know how to create ISeq from: xhealth_web.db.migrations$mig_user_role_on_dev_user
I have decided that my brain for some reason does not possess the processing power to solve this. 😞
Does anyone know what my problem might be??
(with the code that is - not my head) 😛
arent I to put datalog querys in a list ahead of time i.e. '
And.... a lesson in.... arrogance of mind? or rigidity of mind perhaps.... the first part of the stack trace I dismissed as being... not relavant -- it was someone elses code - it had to work correctly. But, how we roll through our migrations, usually its data-attributes not functions that perform queries and subsequent updates.... So, in the config I had to handle mine slightly differantly.....
I'm going through Datomic's HA documentation, it says something about a "Datomic transactor appliance", in context: > If you are using the Datomic transactor appliance, you can run two transactors in a single stack by setting a property in your CloudFormation template > https://docs.datomic.com/on-prem/ha.html#enabling Does any one know what this means?
@franquito https://docs.datomic.com/on-prem/aws.html <-- that would be if you're using a Cloudformation template to spin up a datomic transactor automatically
But if you're on AWS, and haven't chosen how to run datomic yet, I would encourage you to look at Datomic Cloud
I think there is less stuff to manage with Datomic Cloud, even though the total number of pieces is greater
Oh, thanks for the clarification. I'm running Datomic in AWS, but I don't think that whoever deployed it used the Datomic Cloud facilities. I do have a CloudFormation template, but the property to adjust the amount of transactors is called GroupSize
instead of aws-autoscaling-group-size
.
Hi @franquito the difference you are seeing is an artifact of the provided CFT process. For running AWS in on-prem we supply a CFT process, described here. https://docs.datomic.com/on-prem/aws.html#create-cloudformation-template That process takes a transactor properties file and a my-cf.propertied file to generate the final CFT.
Thank you! I double checked just in case. Apparently we did use the CFT sample Datomic provides and it transforms the aws-autoscaling-group-size
property to a parameter GroupSize
of the template.
Hey all, I work with @franquito. Following up on his question:
We're pretty deep in On-Prem now even though it is on AWS—it's already running in production backed with DynamoDB. Unless I'm misunderstanding https://docs.datomic.com/on-prem/moving-to-cloud.html, it seems at this point it'd be pretty painful to switch to Cloud.
But my question is: does aws-autoscaling-group-size
in the CloudFormation .template
file translate directly to GroupSize
in the Template JSON I'm seeing in AWS CloudFormation console now, after it was successfully created?
Excerpt from our CloudFormation Template:
"GroupSize":
{"Description":"Size of machine group",
"Type":"String",
"Default":"2"},
Or is the lack of aws-autoscaling-group-size
in my Template JSON a sign that we've improperly configured our cluster for High Availability?