Fork me on GitHub
#datomic
<
2020-01-14
>
matthavener18:01:44

thank you for removing the peer dependencies!

πŸ‘ 8
grzm19:01:49

I'm looking at spec'ing Datomic data structures (e.g., data in tx-data and results from queries and pull). For the most part, it's pretty straightforward. One wrinkle is references: the value can be a variety of things, such as a long (the entity id), any of the different lookup-ref forms, or a map of the referenced entity attributes (e.g., in result sets). All will have the same key. In some contexts I'll definitely want a lookup-ref as opposed to a map (e.g., in a transaction where I want to reference an extant entity), so I'm wondering how to handle validation. Any ideas on approaches?

Joe Lane20:01:15

Use spec2/union. Look for prior art on folks already attempting to spec datomic. Identify which scenarios you "definitely want a lookup-ref as opposed to a map" and define a different select / union for those scenarios (luckily, you seem to already have identified them!). For speccing the tx-data, just follow the grammar on the docs page.

Joe Lane20:01:31

When in doubt, phone a friend πŸ™‚

grzm20:01:02

Cheers! is there a reference for union? I don't see it immediately at hand on the wiki Looks like it's on the schema/select page.

alexmiller20:01:02

unions are probably going to go away or change name, so don't lean on that too hard

grzm20:01:03

That being the case, would you have a pointer towards another approach I might take? Where in some contexts, I want tighter validation than others for the same spec/key?

alexmiller20:01:57

is there some reason not to s/or all the options?

alexmiller20:01:10

and then s/and in more constrained predicates when needed?

alexmiller20:01:24

and separately, are these tighter constraints actually helping you enough to be worth the trouble?

grzm20:01:24

Say I'm using Datomic-like data structures in my application, as Datomic is my primary data store and they're nice data structures to do business logic on anyway. I have a new (not yet persisted) entity that contains a reference to another, (should-be-pre-existing) entity. If I want to transact that data, I'll use a look-up ref (which will guarantee failure if that entity doesn't already exist, which is what I want). If I use a map as that reference, it will create that entity (which is not what I want). I can create a spec that accepts a map or a lookup-ref as valid values for the key, but in the tx-data case, I only want the lookup-ref version, not the map version. Am I thinking about this wrong?

favila20:01:57

Stepping back, datomic transactions are a DSL. does it make sense to spec it as a DSL, or to spec your particular use of it?

πŸš€ 4
favila20:01:19

The latter is going to be a challenge because the meaning of keys is overloaded

favila20:01:36

As a DSL, the keys are opaque and meaningless

favila21:01:22

but if you try to spec the DSL at a more semantic level, you may conflict with the β€œread” view of those keys (i.e. what you get from d/pull, etc)

alexmiller21:01:30

sometimes, it's just not worth getting down to that level of specificity

favila21:01:03

or if you need to, consider making a new DSL for your transactions, and speccing that instead

favila21:01:26

and have functions that transform to the transaction dsl

grzm21:01:06

@U09R86PA4 that makes sense. Cheers.

grzm21:01:45

Stronger than that. @U09R86PA4 that really clarifying. doubleplussgood

Joe Lane20:01:18

Noted πŸ‘

djeis20:01:58

Is it possible to use classpath functions with an in-memory database created with the peer library?

djeis21:01:13

My impression at a high-level from the docs and discussions online is it should be, but it seems no matter what I do I get :db.error/not-a-data-function so clearly either I've misunderstood something or I'm doing something fundamentally wrong.

djeis22:01:33

Ah, I think I figured it out... The latest version of datomic free in clojars doesn't support classpath functions. πŸ˜“