@mtnygard regarding spec validation. I just realize that when we write spec for vase, we have to write spec to validate the whole stuff {:payload [::entity-maps]} instead of only for entity-map. I'm not sure if this only happens when I include external specs ( those which are not defined in descriptor ) or not ? And I think this is worth mentioning in docs.

@nxqd Yeah, that has more to do with the Transact action than where the specs are defined. If you were validating params to a Query, or using Conform to reshape the results of a query, then that wouldn't apply.

@mtnygard, following up on your offer to help at https://github.com/cognitect-labs/vase/issues/50. Thanks!

Welcome @deg!

So, it's not clear to me if I need to do any Datomic config to start using Vase. Or, can I just treat it as a black box for a while?

If you just want to use an in-memory database, then you don't have to download or run anything. Can you paste in the value of your :datomic-api key? That will tell us what "storage" you'll be using.

From which file? A quick grep did not find it.

It would be under resources, in a file with ".edn" as the extension.

maybe datomic-uri?

Doh. Yeah, I'm not going be much help if I mistype things... Yes, :datomic-uri

:datomic-uri "datomic:<mem://example>"

🙂

OK, the "mem" part of that means you're using the in-memory database. That runs completely inside your Java process so you don't need to set anything else up.

Cool.

The down side, naturally, is that it doesn't persist.

Does it also persist to file?

Hmm

So, I'll be coming back to a blank slate anytime I restart the program?

Right, not only that, but you can create a new memory DB anytime to get a blank state. There's a "dev" mode that does persist to a file. To use that, you'll need to download Datomic Starter or Datomic Free.

Ok. So, looks like the docs are a bit inconsistent about this. I guess in part because Vase development overlapped Cognitect's recent change of tiers.

Hmm, that's probably true.

Where should I read to figure out the simplest way to do this integration?

The "getting started" docs for datomic aren't the greatest (being revised now, in fact) but they should get you going. http://docs.datomic.com/get-datomic.html

And, for the docs, it would be great to have this built in as an option. I suspect for Vase to win, it's going to need to attract a lot of new people to the full Datomic env.

Thanks. Getting late here, and then I'm off for a few days. But, I will tackle this next week and -- I suspect -- will bother you then with more questions. Thanks!

You'll run a thing called a "transactor" as a separate process, then change the :datomic-uri to something like "datomic:<free://localhost:4334/<dbname>>"

I'm heading out for Spring Break over the next week, but you can email me at <mailto:[email protected]|[email protected]> in the meantime.

Can I ask what led you to consider Vase? I'm always interested in where our users see value.

Enjoy. (drinks on beach emoji)

I listen to the Cognicast podcast, and it was talked about a few weeks back. Also, I saw it mentioned in various online places

Cool! Thanks.

And, I recently wrote a hobbyist CLJ/CLJS project with much too much scaffolding and no DB support, so was receptive to the right tools.

haha ... that's exactly why we made Vase!

same frustration.

I'm still not totally sure that I buy into the persistent DB idea for dev work, so suspect I'll be cursing it for a while, while I radically refactor early stage code. But, can certainly see how it will win big for production deployments.

So, when you get to unit testing, we've got a cool story... basically you can make a fixture that wraps each test with its own in-memory db. so no need to mock out the database when you can always have an isolated instance. the main trick is generating a dbname via UUID. Like (str "datomic:mem://" (d/squuid))

That is cool! Anyway, I'm just entering the foothills of the learning curve.

Running late here (I'm seven hours ahead of EST), so I'm gonna drop off now. Thanks again.

Cheers

Hey, how to use io.pedestal.interceptor.error/error-dispatchwith datomic? I can't make patterns to catch datomic exceptions

@souenzzo If one of your interceptors throws an exception, including one from Datomic, Pedestal's chain handler will catch it and turn it into data. It's that data that you pattern-match in error-dispatch

But datomic exceptions match just on generic :exception-type :java.util.concurrent.ExecutionException or :exception-type :java.lang.IllegalArgumentException (Nothing guarantees me that only datomic exceptions entered here) Then I need to some nested .getCause, ex-data and make another router.... I did not know if there was a standard solution

I see what you mean. I suppose you could also match on the interceptor name that's throwing the exception.

There might be another trick to apply. One sec while I look at the source.

OK, here's an avenue you might explore. error-dispatch uses core.match under the hood. It tries to unify the exception data against your patterns. The examples are all of basic map matching, but you can use any of the patterns in https://github.com/clojure/core.match/wiki/Overview that would work on the ex-data. That should include guard clauses on .getCause of the underlying exception.