This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # aleph (16)
- # announcements (8)
- # aws (5)
- # babashka (57)
- # beginners (48)
- # calva (7)
- # cider (7)
- # clojure (209)
- # clojure-brasil (4)
- # clojure-europe (20)
- # clojure-italy (12)
- # clojure-nl (21)
- # clojure-uk (69)
- # clojurescript (24)
- # cursive (11)
- # datascript (7)
- # datomic (47)
- # emacs (14)
- # graphql (20)
- # hoplon (25)
- # jobs (1)
- # kaocha (1)
- # leiningen (14)
- # meander (7)
- # off-topic (44)
- # other-languages (1)
- # pathom (20)
- # re-frame (2)
- # reagent (51)
- # reitit (3)
- # remote-jobs (1)
- # shadow-cljs (46)
- # spacemacs (5)
- # sql (65)
- # tools-deps (86)
- # vim (11)
Hi, any opinions on using fully namespaced spected keywords as datomic attributes? Like org.domain.entity/attribute?
One issue that I’ve found is trying to spec ref attributes, where I can have the actual entity or a lookup ref when transacting. It’s seems a bit weird to have the domain this close to a db spec.
can u give a specific example of that spec situation?
this sounds like an interesting problem.
i was also wondering about what is a good naming scheme for specs.
for now i just went with the
problem-domain-entity-name/attr style, and my namespaces dealing with those attributes are
<company-short-name>.<project-name>.data.<problem-domain-entity-name> or maybe don't even have the
.data part if the project is simple enough.
company internet domain: https://gini.co
domain entity terminology: financial transaction
domain entity name:
txn (as opposed to
tx, which we kept to refer to Datomic transactions)
I've also tried to just have
gini.txn, but it's easy to get lost between projects within a monorepo, where different projects might deal with different aspects of the same domain entity...
Imo it’s not appropriate to spec txdata for d/transact. The spec for transaction data is the spec for the transaction dsl, not for its keys
Cool, I’m sharing this opinion now. What do you think about the namespaces? There is a lot of boilerplate when converting between them, having the same attributes internally and in datomic solves some of the issue. Wire Internal Datomic :attribute <-> org.domain.entity/attribute <-> :entity/attribute
If you can somehow maneuver your data keyword namespaces to be actual namespaces (maybe put specs there? idk) your life will be much better, or at least not have as much keyword typing in it
I’m doing that, the actual length is not an issue (only in repl things get polluted sometimes). Our convention is to wire unnamespaced between services, but it’s not hard to namespace all things, the issue is more between internal and datomic schemas.
About the org, we thought on using it because it would be clearer when it’s an external data from a provider, for example.
Is there a way to get the database URI back from a
If not, is there a reason for it?
Eg. not to keep connection secrets for a DynamoDB connection around for long (when someone is using the not-recommended non-role based uri)?
It would be convenient to obtain a connection URI back from a
conn, when creating a Datomic component using some state management library, like
It could simplify the stop operation, which can automatically clean up in-memory test databases with random names for example...
morning folks - just testing my thinking... if I accidentally deferred giving my datomic compute instance an application name during template setup etc (working through the ion tutorial) - would I be right in thinking there should be a way to give a value to that parameter in AWS console ? Thanks.
It will automatically get the application name of the compute group, but you can also change it by doing an “update stack” in the cloudformation console
this may be a dumb question but if you're querying with a vector of values is there a way to count how many values in a muli-valued attribute you matched on?
I want to use Java 11 lambda ions in Datomic Cloud. My IDE and libraries are set up for Java 11 on my local machine, but it still deploys Java 8. Any suggestions?
the lambdas are cookie-cutter forwarding proxies that talk to the compute group, which actually runs your code
Not sure what the timeline is on Java 11 support. I'm sure it's on the roadmap but not sure where
incidentally I have been working on a AWS Lambda custom runtime for clojure -- as a separate effort
can run Java 14 in the Lambda, where your function handler is an ordinary var that gets called with ordinary maps as arguments, and returns a map
Personally I like the http://java.net.http client being available. Cuts down on a lot of deps.
No, I was hoping to get a little more speed out of the JVM. Want to use the latest and greatest before going to Production.