This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-10-07
Channels
- # announcements (9)
- # beginners (155)
- # bristol-clojurians (1)
- # calva (49)
- # chlorine-clover (36)
- # cider (10)
- # clara (6)
- # clj-kondo (14)
- # clojars (28)
- # clojure (226)
- # clojure-australia (1)
- # clojure-berlin (12)
- # clojure-czech (1)
- # clojure-europe (26)
- # clojure-germany (1)
- # clojure-nl (2)
- # clojure-uk (32)
- # clojurescript (9)
- # conjure (21)
- # datascript (3)
- # datomic (43)
- # emacs (3)
- # figwheel-main (16)
- # fulcro (17)
- # graalvm (9)
- # helix (4)
- # lambdaisland (3)
- # malli (13)
- # off-topic (12)
- # pathom (7)
- # re-frame (10)
- # reitit (9)
- # rewrite-clj (2)
- # shadow-cljs (41)
- # spacemacs (6)
- # specter (3)
- # test-check (5)
- # tools-deps (9)
- # tree-sitter (1)
- # vim (15)
- # xtdb (3)
Is there a library out there such that whether using :peer
or :client
is mostly unknown from your application code's point of view?
You can use the client library to connect to an on-prem peer server. The client library is the lowest common denominator in that sense ^^
Yes, in a sense the peer library is on the way out?? I was asking because I use such a peer/client ambivalent library internally, and was thinking to make it open source.
Well I’m not at cognitect, so I can’t answer that. But if you intend to migrate from on-prem to the cloud at some point, you are better off with the client api, so it appears to be ‘good advice’ to start new projects with the client api
Also; there are quite a few subtle differences between the api’s. The query dialect is slightly different (most notably, not all :find
specs in peer are supported in client), and many functions have slightly different arguments/return values (for example, many functions return deref’able things in peer, but direct results in client).
I must have ignored the 'good advice' initially, hence the compatibility library. For the :find
differences I've just changed all the queries to work for the client, which means they can work for both. Other subtleties I've found have just been taken care of by the library - basically it is a map that includes some wrapper functions that choose to use one function or the other - for example either one of the two variants of transact
, depending on the 'mode' being used.
Can't I build/push a datomic ion that includes an alias? Meaning: I have an application and bundle datomic-ion specific stuff under a :datomic
alias. I then want to push it like this: clojure -M:datomic:ion-dev '{:op :push}'
, but when I check the zip file that's generated all the stuff from my alias (specific namespaces & resources) is missing. Am I doing something wrong or is this just not supported?
not with new clj ...
I actually tried both and various combinations thereof yesterday. My initial cmd was clojure -A:datomic -M:ion-dev ...
and I also tried the variant straight from the docs: clojure -A:datomic:ion-dev -m datomic.ion.dev '{:op :push (options)}'
to no avail. But I can double check again.
On another note:
Right now, I've pulled all my deps from the alias into my main deps so I can at least try the deployment of my lambda proxy.
Now I'm a step further, I see in the Api Gateway console that my app is returning a proper ring response, but the lambda crashes with a 502 error:
> Wed Oct 07 13:51:50 UTC 2020 : Execution failed due to configuration error: Malformed Lambda proxy response
> Wed Oct 07 13:51:50 UTC 2020 : Method completed with status: 502
The only thing I don't see in my response body is the isBase64Encoded
flag, so maybe that's the issue right now
which doc was clojure -A:datomic:ion-dev -m datomic.ion.dev '{:op :push (options)}'
from ?
From what I've seen so far it's every command in the ion tutorials, e.g. https://docs.datomic.com/cloud/ions/ions-reference.html#push
The ion tutorials would also need some updates regarding the new AWS Api-Gateway Options, see here: https://clojurians.slack.com/archives/C03RZMDSH/p1601380150089100
thanks those commands seem wrong - if using :ion-dev with a :main-opts, the -m datomic.ion.dev
isn't need there /cc @U05120CBV
yes, that clj syntax is fine with the new clj (but I don't think that has anything to do with your issue)
If you mean dev-local, once you’ve made a client (https://docs.datomic.com/cloud/dev-local.html#using) you can use it exactly the same way as you would using client against cloud (i.e. you can call create-database
https://docs.datomic.com/client-api/datomic.client.api.html#var-create-database)
I do recall creating the database from the cmd line argument when using Datomic on premise locally on my computer
generally that would not be the case unless you were just using peer-server with a mem
database
@rob703 what versions of the various ion tools are you using? I’m going to try to reproduce/investigate
> it only contains your ion code Yes, that's the other part of my problem, it's not only the deps but also the additional paths. For example:
:aliases {:datomic {:extra-paths ["src/datomic"]}}
My entire code in the datomic folder is missingfor now I would say you’ll want to put those extra paths in the main body of the deps, not in an alias
Yeah I moved everything from my alias up for now. I'm now battling with AWS itself, trying to get the lambda proxy to work. But that's another issue in itself
Is there a clear example of using :db.entity/preds? I have defined it as {:db/ident :transaction/pred
:db.entity/preds 'ledger.transaction/existing-transaction-entity-pred}
When I try and transact with (d/transact conn {:tx-data [{:transaction/user-id #uuid "9550f401-fb16-4e42-8940-d683dbad3a3d" :transaction/txn-hash "Pl3b9f7ba2-eb0d-412d-b305-f76b5150c711" :db/ensure :transaction/pred}]})