Fork me on GitHub
#datomic
<
2017-08-01
>
hmaurer13:08:18

Are you aware of a reason why this project in particular hasn’t been maintained in a while? More specifically, was the approach abandoned because of major flaws, or just lack of time / interest?

marshall13:08:24

I believe it was intended as a framework for this type of problem, as opposed to a ready-to-go library. Also, I don’t think anything about the Datomic schema or interfaces has changed since it was last released so I don’t see why it wouldn’t continue to work as-is

hmaurer13:08:09

@U05120CBV Ok, thanks! I was just curious as to whether the person working on this project (from Cognitect, it seems) found it unsuitable as an approach to model data in datomic and therefore abandoned the idea

marshall14:08:08

No, I believe it was felt to be a good approach when necessary/appropriate

souenzzo18:08:30

Why I can't do [:find ?e ?e ...]?? Is it intentional? There is some workaround?

hmaurer18:08:39

@souenzzo what’s your use-case?

souenzzo13:08:20

I'm doing :find ?e (pull ?e [*]) (pull ?f [*]) Then, when I'm processing, pure ?e means "you should do some calculus about ?e" and (pull ?e [*]) is just a map of random attributues

hmaurer13:08:42

@souenzzo ?e will have the same value as :db/id in the map returned by pull

souenzzo13:08:52

Yep. I made it. But I see no reason to this limitation

val_waeselynck16:08:56

neither do I, and I've been bit by this kind of limitation when doing code generation among other things

hmaurer21:08:44

Question: why does datomic.api/transact takes a vector as tx-data and not a set?

favila21:08:42

transaction functions are not necessarily pure @hmaurer

hmaurer22:08:23

@favila ah, right. Are they executed in the order of the vector of tx-data?

favila22:08:45

no idea. I expect there are no guarantees

favila22:08:13

what matters is what they return. It's the final expansion that has set semantics

hmaurer22:08:32

@favila speaking of, is there a way to expand the tx-data locally? not the transaction functions, but at least expand the “map” shorthand into assertions

hmaurer22:08:48

I mean, without writing a function to do the expansion of course

favila22:08:19

the transaction functions are just functions, you can invoke them directly to see what they expand to

favila22:08:36

I think the only way to see map expansion is d/with

hmaurer22:08:00

how will with work with tx functions? I assume it won’t know about the ones installed on the transactor?

favila22:08:13

of course it will

favila22:08:45

they may not run if their dependencies are not satisfied

hmaurer22:08:19

Ok, I see. thanks 🙂

favila22:08:48

you can pull a function out of the db and call it

favila22:08:23

they're created by d/function

hmaurer22:08:26

yeah actually I hadn’t really read the doc about transaction functions yet. I just realised they are just data stored in the db

favila22:08:06

as long as its :imports and :requires are on the peer (and compatible with whatever the transactor has), it will run just like on the transactor