Fork me on GitHub
#datomic
<
2017-12-01
>
Oliver George02:12:55

Hello. Can someone clarify how licensing works for developers. I think each registration is allowed one license for Datomic Starter with 1 year of upgrades. Does that mean each dev on my team will be unable to access a current version of Datomic Starter for development purposes after 1 year?

Oliver George02:12:52

For example, I poked around with Datomic briefly in 2014 and I can't see any way to "renew" my starter license.

sb13:12:38

Do you have a great tutorial how to import logs with timestamps into Datomic? I saw I need to use :db/txInstant .. as when the transaction recorded.. just would be great an example. thx

sb14:12:38

{:db/id "datomic.tx"
 :db/txInstant #inst "2014-02-28"}]

sb14:12:23

What is the best case?

donaldball15:12:59

I believe the advice is not to use :db/txInstant to record the instant at which the observations within a transaction occurred, unless perhaps you have an irrefutable guarantee that you will never ever need to import your logs in any order.

sb16:12:19

thank you for your advice, how can I import large logs with ts in Datomic (sorry for the beginner question)?

souenzzo16:12:00

it's about backup/restore?

sb17:12:28

I have a database (I can transform to json or any format, like a big log) and I would like to import to Datomic.

sb17:12:45

I would like to add new records to this db in Datomic

sb17:12:27

(timestamps very critical) / I don`t know.. it might be good if I use manual timestamps or maybe here is more elegant solution

souenzzo18:12:50

no idea. 😕 But I'm also interested.

marshall19:12:11

setting explicit txInstant on import is intended for this type of use

marshall19:12:17

one second, i’ll get you the docs and an example

sb19:12:26

Ok, thanks!!

marshall19:12:45

Note that you have to assert them in order, so you need to sort your source data in ascending time order

marshall19:12:08

Datomic will not allow you to specify a txInstant that is older than the newest that already exists in the db

sb19:12:54

Ok! that is important! thank you very much!!

sb19:12:27

thanks @U05120CBV @U2J4FRT2T 👍👍👍

jaret19:12:21

http://docs.datomic.com/deployment.html#upgrading-live-system @laujensen This section of docs covers updating a Datomic system. >To upgrade the transactor, start a new transactor (or pair of transactors) based on the release of Datomic you are upgrading to. Once these processes are up and monitoring the storage heartbeat, kill the old transactors and the new ones will automatically take over. >To upgrade peer applications, simply start new peers and take down old ones. You can stagger the ups and downs to maintain availability during the upgrade.

kenbier23:12:36

Does anyone have experience with using Datomic from a non clojure project? Say Java, Ruby, or NodeJS? Curious how your experience was. I used datomic in a clojure project on my last team and everyone loved it. I recommended it to my team, and they are really excited about the auditing capabilities Datomic provides. Its likely we won’t be using clojure though.

steveb8n09:12:08

I’m interested in this too. Specifically node.js on AWS lambda via the client api

sb13:12:34

If I remember good then Datomic.. have Nodejs library, Ruby and Python. I don’t have experience.

steveb8n21:12:52

The nodejs lib uses the (old) rest api, to use the new Datomic Cloud service, we need client api support. Nodejs has the best cold-start time for AWS Lambda so it is preferable.

sb14:12:34

I created in the past therefore a multi-route java lambda which in one “line” running like a logger (run automatically), in other 5-6 routes.. solved the cold start problems. In this way, system was faster.

steveb8n04:12:01

that only helps the cold start from zero problem i.e. when scaling up under load, there are more cold starts that users will see

steveb8n04:12:34

I’m pretty sure this use case is why the client API was created. Looking forward to an official client that works for a fast-starting lambda