This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # beginners (205)
- # boot (6)
- # cider (22)
- # cljs-dev (41)
- # cljsrn (4)
- # clojure (97)
- # clojure-dev (61)
- # clojure-greece (40)
- # clojure-italy (8)
- # clojure-russia (16)
- # clojure-spec (18)
- # clojure-uk (34)
- # clojurescript (14)
- # community-development (1)
- # cursive (45)
- # datomic (39)
- # fulcro (66)
- # jobs (2)
- # lein-figwheel (1)
- # lumo (9)
- # off-topic (8)
- # parinfer (98)
- # portkey (8)
- # re-frame (81)
- # reagent (54)
- # remote-jobs (17)
- # ring (2)
- # shadow-cljs (217)
- # spacemacs (32)
- # sql (24)
- # test-check (6)
- # unrepl (73)
- # yada (12)
@marshall Thanks, I missed that info. In the meantime while we wait for a spec is the REST api the correct way to go (even though deprecated)?
@julienlucvincent You can also go to http://my.datomic.com -> log in ->
@marshall Thanks again for your help the other day - turns out our issues with the license upgrade were all unforced errors on our part, but your patience and willingness to help us get more information about what our stack was doing helped a lot
I’ve made some …improvements to the non-automated parts of that process for us that should prevent that particular footgun from going off again
@julienlucvincent as @chris_johnson said, there are several requests in the feature portal What language specifically are you wanting to use? One consideration with the REST server is that it is On-Prem only, so if you want to target Datomic Cloud you’ll probably want to do something more like a thin wrapper around the Clojure client API
@marshall @chris_johnson For now I am more investigating what would be available to me if I moved my org to datomic. We have some existing systems in JS in addition to Clojure and so some sort of JS interop would likely be required. I like the suggestion about a wrapper around a clojure client, that sounds preferable over the REST api.
then, yes, if you want to move toward Datomic prior to the release of the wire protocol details, I’d say something like a wrapper on the client would be what I would consider especially if you already have Clojure in some systems and some Clojure experience
@alex438 https://docs.datomic.com/on-prem/moving-to-cloud.html#sec-3 Cloud can only be used from the Client API. What specific aspect(s) of Peers are you wanting? We’re considering options for supporting functionalities of Peer (i.e. code colocated with data) for Cloud
@marshall I’m very interested in this idea. I want to move to cloud but I have lots of code that assumes peer/cheap pull/entity/q calls that would need to be migrated/optimised. peer support would save me a lot of work. it would also be a very valuable feature for cloud because the “cache in peer” design is powerful and a real distinction between Datomic and most other databases
every time we write code to optimise network round trips, it adds complexity. not worrying about network vastly simplifies the code, and allowing some lazy coding practices, which is great for fast prototyping and experimentation
+1 to this, I also find it to be much easier to architect around entity api.
Being able to query without regard for round trips is a fantastic selling point for D in general, not to mention the queries are simpler to write because you don’t have to use pull
I plan to ingest and persist many different datasets (eg. from CSV files or intermediate computational results). For each of the ingested columns I currently create a new attribute (with some meta-data like a business level data-type or provenance information). Is this approach feasible? What do I need to consider regarding an ever growing set of attributes, indexing, etc.?
@jocrau The limit of number of schema elements is 2^20 https://docs.datomic.com/on-prem/schema.html#schema-limits
That could happen if I store intermediate computation results. But there are ways to mitigate that (reusing existing attributes, recreating the database, etc.). What is the technical reason to limit schema elements to 2^20?
The way I use attributes is not the standard Datomic way which relies on the
:db/ident of the attribute to “discover” data. It usually well known, human readable name like
:person/first-name. My approach is to discover similar values by looking for meta-data on attributes and have generated attribute idents (like
@jocrau there are definitely users with dynamically created attributes with generated IDs, nothing wrong with that approach as long as you keep the 2^20 limit in mind
@marshall around how long will that process of gathering information and finalising the spec take?
@jocrau I thought your question and discussion with Marshall would make a good discussion topic for our forums. I took the liberty of summarizing the question and answer here https://forum.datomic.com/t/total-number-of-attributes/325
I am hoping to make these types of probelms/questions searchable by posting there. If you think I am missing anything or would like to add an experience report to that thread it would be much appreciated
I’m having some problems getting datomic cloud client to play well with jetty in my app. It looks like datomic includes cognitec http client which pulls in an old version of jetty. I added the exclusions as mentioned in the docs but then I get class not found, jetty.client.HttpClient, errors unless I specifically add back in jetty dependencies. But then with 9.4.8 I get new class not found errors HttpParser$ProxyHandler unless I use a slightly older version of jetty (9.2.9)… when I get illegalstateexceptions: SSl doesnt have a valid keystore … does anyone know know what version of jetty is compatible and/or what I’m doing wrong? Thanks in advance.