This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-12-19
Channels
- # adventofcode (44)
- # announcements (2)
- # aws (9)
- # beginners (166)
- # braveandtrue (16)
- # calva (170)
- # cider (14)
- # cljdoc (9)
- # cljs-dev (4)
- # cljsrn (1)
- # clojars (1)
- # clojure (150)
- # clojure-dev (15)
- # clojure-europe (4)
- # clojure-india (3)
- # clojure-italy (93)
- # clojure-nl (18)
- # clojure-serbia (1)
- # clojure-spec (5)
- # clojure-uk (45)
- # clojurescript (54)
- # cursive (19)
- # data-science (8)
- # datomic (83)
- # emacs (6)
- # events (1)
- # hoplon (3)
- # hyperfiddle (3)
- # jobs (6)
- # jobs-discuss (1)
- # klipse (1)
- # lein-figwheel (6)
- # leiningen (15)
- # lumo (1)
- # nrepl (1)
- # pedestal (15)
- # re-frame (48)
- # reagent (4)
- # reitit (2)
- # remote-jobs (1)
- # rum (2)
- # shadow-cljs (111)
- # spacemacs (10)
- # sql (16)
- # testing (10)
- # tools-deps (5)
Does anyone know how to resolve refs in nested maps when transacting data? Say I have a vector of maps:
{:account/id 42
:account/likes [{:like/id [:account/id 5166]}]}
But when I load the whole dataset, Datomic says
Unable to resolve entity: [:account/id 5166] in datom [-9223301668109571139 :like/id [:account/id 5166]]
Yet the account 5166 really exists in the vector.
What should I do?it suppose to be :db/id
, isnt it?
> When used in a transaction, the lookup ref is evaluated against the specified attribute's index as it exists before the transaction is processed, so you cannot use a lookup ref to lookup an entity being defined in the same transaction.
do you use pull api?
are they reference not by :db/id?
are you sure id is correct?
can you pull data with this lookup?
yes. for example, I don’t load likes at all, but then I can pull a user with such id
otherwise you cant lookup, right?
interesting, thanks for that case 🙂
didnt know datomic can do like this
I'm getting a ssh: connect to host [ip] port 22: Connection refused
on a fresh Datomic Cloud stack. Other ssh connections work. Is there a way to trouble shoot?
Ok, that was a problem of parallelism. I was being clever and set up the permissions as soon as they appeared in the AWS Console, but before the stack formation completed... Restarting the bastion server helped...
I'm trying to understand the estimated costs of Datomic Cloud using the calculator at https://aws.amazon.com/marketplace/pp/prodview-otb76awcrb7aa?ref=vdr_rf. The "Datomic Cloud" choice is kind of confusing. If I choose a particular EC2 type (e.g. i3.xlarge) it has a Software/hr and an EC2/hr price along with a Total/hr price (e.g. $0.312, $0.312, $0.624). This selection is then reflected in the "Estimated Infrastructure Cost," but only the "1/2 value" is used (e.g. $0.312). What is the actual number I should use to estimate my costs for a month of usage with a particular config? To keep it simple, let's say I choose i3.xlarge (costs shown above) and have one instance running 24/7 for a 30 day period. Would I expect to pay 24 x 7 x $0.312 = $224.64 or twice that? We can ignore data storage for the moment. It looks like that is just $0.10/GB-month.
Twice that, since production requires at least two nodes, so $224 x 2 for the i3.large, for the i3.xlarge would be $449 x 2
don't forget storage and data transfer costs and other aws services datomic cloud uses 😉
The two nodes isn't baked in to the config? Is the second for HA?
but I don't think you can start with i3.xlarge though, these instances are only enabled as additions to the production i3.large ones
@markbastian The estimate per hour for the solo topology comes out the same as production if you set them both to the same instance type, so I would expect to estimate twice what the tool shows for the production topology. I think it's a limitation in the estimation tool - hopefully someone who knows for sure will give you a more certain answer.
Yeah, the choice of solo vs. prod vs. anything else in the "Fulfillment Option" dropdown doesn't seem to have any effect on the details. I think it's what you choose. Even then, though, there isn't any "bottom line" number. The "Datomic Cloud" choice you make only reflects the Software/hr price and the "Estimated Infrastructure Cost" seems to reflect the EC2/hr price. I'm guessing the actual cost is the Total/hr, but I don't know if you get billed again for the Estimated Infrastracture Cost item. If solo is $1/day the answer the agrees best with that would be $0.035/hr (Total/hr).
Twice that, since production requires at least two nodes, so $224 x 2 for the i3.large, for the i3.xlarge would be $449 x 2
The two nodes isn't baked in to the config? Is the second for HA?
Is is Incorrect to assert :db/doc
values on entities that have :db/ident
values but are not actually attribute entities?
As long as it respects the semantic of the attribute which is "Documentation string for an entity".
Hey friends, I’m x-posting from the datomic forum. Looking for guidance on Cognito claims information in the ion apigw request object. Is it stable? Was this documented and I missed it? https://forum.datomic.com/t/datomic-ions-using-cognito-user-pool-apigateway-authorizer/748?u=jplane
I looked into this as well. I’m currently using AppSync which means I have an extra VTL transform layer so I can’t help with API-GW specific knowledge
it’s annoying because you need the access token to make your request but that token doesn’t contain claims
There were so many problems I ran into that didn’t even throw errors I just dropped it.
I think AppSync is good if you want to use Amplify.js but otherwise it’s extra complexity for not much extra value
it's ok to share :db/id for short-lived uses (interactive, in-memory); it's ok to not give an external identifier to entities you don't want to be directly addressable from outside your system.
entities at the other end of an is-component attribute usually should not have an external id
exactly the case I was figuring it out for (entities that belong to others by means of :db.type/ref and isComponent, and not directly addressable), couldn't think of a use case for given them external keys, thx.
I have a UUID on every entity in my db. It is useful for a lot of reasons so I consider this a best practice now
In some cases I also derive (type 3) UUIDs from entities so that I can count on stable ids, even when not persisted
what? how do you do this