This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-07-23
Channels
- # beginners (169)
- # boot (8)
- # cider (20)
- # cljdoc (66)
- # cljs-dev (1)
- # cljsrn (1)
- # clojure (185)
- # clojure-greece (11)
- # clojure-italy (16)
- # clojure-nl (5)
- # clojure-spec (16)
- # clojure-uk (39)
- # clojurescript (11)
- # cursive (26)
- # data-science (2)
- # datavis (1)
- # datomic (40)
- # emacs (10)
- # figwheel-main (64)
- # graphql (10)
- # hyperfiddle (1)
- # jobs (2)
- # leiningen (9)
- # luminus (3)
- # nyc (1)
- # off-topic (19)
- # om (1)
- # onyx (6)
- # pedestal (2)
- # re-frame (35)
- # reagent (17)
- # ring-swagger (9)
- # rum (1)
- # shadow-cljs (42)
- # spacemacs (8)
- # specter (7)
- # tools-deps (4)
- # yada (6)
This is the result of an experiment to automate the API Gateway setup required for Web Service Ions via the aws cli (so each new deployment isn't a manual setup task). I'm interested in any feedback (approach, assumptions, implementation...) https://gist.github.com/olivergeorge/cc0ca9a945cb372d35d97e45573656ee (updated to tidy up)
I did something similar here https://github.com/hlprmnky/ion-appsync-example/blob/master/src-pages/cf/node_pages.clj although not for Ions, instead for CLJS lambdas intended to eventually be the host pages for an Ion backed SPA
Using Crucible and Cloudformation is a pretty nice experience for doing infra as code IMO. I like where all these ideas are taking us
Thanks I'll check it out. Crucible is new to me. Still getting familiar with the AWS landscape.
condensation
is also a fun option for writing infra as code in Clojure. I've had good success working this library into certain deployment workflows.
https://github.com/comoyo/condensation
Now that I look at the cloudformation documentation it does seem like generating a cloudformation template is ultimately a simpler solution.
Is excision CPU bound? Does the way I partition transactions matter? I'm excising 150k entities and wondering how long it'll take
That’s a HUGE excision. Excision is not intended for size control and should be used only when necessary (i.e. legally required to remove something). As a rule of thumb, if you can’t type out the excision transaction manually it’s probably too big to run at once.
@bill_rubin I think it's not so much about size, more a matter of how much it disrupts your indexes.
how long it takes probably depends a lot on your Transactor's hardware, your storage and your network performance characteristics
Does anyone know where I can find the options available for the :headers
field for a web ion?
@val_waeselynck Thanks. It's on a single host and the transactor has been maxing out the cpu overnight so I'm assuming that's the limiting factor. I guess I'll just recreate the db
@bill_rubin you may want to have a look at this: https://gist.github.com/vvvvalvalval/6e1888995fe1a90722818eefae49beaf
@val_waeselynck Yea that's what I'm doing haha, thanks!
Also @henrik, since what’s coming in is basically ring-compatible, you can drop right into one of the various and sundry routing/middleware libs if your use case is non-trivial. I just swapped out some custom code for reitit literally last night
I’m trying a simple retraction on Datomic Cloud and getting a weird error. The retraction is: [[:db/retract :person/email :db/unique :db.unique/identity]]
(yes, the dataset I’m working on does not guarantee unique emails for some bizarre reason).
Great @marshall! Thanks a lot. Do you know if it would work in the very same transaction where I’m in fact asserting duplicate emails, or do I need to keep two separate transactions?
What about the opposite scenario? (trying to prepare for the future). When I manage to implement a transaction that fixes the dataset in the live system, I’ll need to make sure that I’m updating all duplicate emails in the same transaction I’m adding the :db/unique back in.
“If there are values present for that attribute, they must be unique in the set of current database assertions.”
so you’d have to update things to make them unique then issue the schema change transaction
hey to the datomic folks, I dropped in a couple feature requests. I’d talked to stu about supporting deploying into existing vpc’s, based on that discussion I know part of the desire is to keep things as contained as possible from a support perspective. But, I think this will be pretty important in the context of datomic cloud’s inevitable massive growth 🙂 Say in our case, we’ve gone from a kind of cheesy, ad-hoc couple vpc’s across two accounts (prod v non-prod) to a 1-1 account/vpc approach for dev,test,etc complemented by shared vpcs for management, ingress etc. with IPSec vpn’s wiring them together. It’s kind of hard to shoehorn extra dedicated datomic VPC’s, per env into this. ions can complicate this further. Since the code is effectively global, I’d like to give each of my devs their own solo system, then have a common ‘dev’ system that’s updated via CI or something. It’d potentially be more manageable to support multiple systems/vpc. Just a few thoughts 😉 In the meantime, ions, are fricking amazing 😉
anyone have any tips on how to write tests for queries that use the :db/txInstant field? i'm having trouble fixturing test data without doing a (Thread/sleep ..)
between calls to transact
You can pass a instant to your transaction to arbitrarily set the time of the transaction. All that datomic cares about is that the txInstants are monotonic
When testing my Ion endpoint via the Method Test UI in the AWS Console, my response body is base64 encoded. Is there a way to get the UI to display the decoded version?
is :db/index not supported in datomic cloud? when I try to do (dc/pull db '[*] :db/index) I get #:db{:id nil}
@shaunxcode yes, :db/index is not supported https://docs.datomic.com/cloud/schema/schema-reference.html