Fork me on GitHub
#datomic
<
2016-09-07
>
robert-stuttaford06:09:03

the most recently modified file in the roots folder will do, @kenny

achesnais07:09:15

Hi all 🙂 quick question: when using lookup-ref in parametrised queries, what is the ref resolved against? The most recent available index, or the datasource provided in the query?

val_waeselynck08:09:37

@achesnais I experimented a bit, AFAICT it's definitely from a data source

val_waeselynck08:09:50

but if there are several data sources not sure what's going on

val_waeselynck08:09:51

it seems to me it gets resolved once per datasource used in a Datalog clause involving the entity

achesnais10:09:26

In your ‘ambiguous data source’ example, isn’t the error stemming from the fact that only $ can be an implicit datasource, meaning that if you don’t specify it in the :in clause datomic won’t know where to find it?

achesnais10:09:55

example 2 is super super interesting. I would have expected it not to work if [:a/id …] were to resolve to the entity within the data source, but it seems what’s binding is indeed the lookup-ref itself

achesnais10:09:12

or rather, it seems that the resolution is limited to the clause scope meaning this works because you’re not passing raw id directly

achesnais10:09:55

And thanks for taking time to experiment @val_waeselynck

misha10:09:40

@robert-stuttaford greetings! Do you store datetime/user-id on a "data-entity" or on a transaction data? How does it work for you in datascript (level of convenience)? Currently, I am storing those on data, but feels like a bit dirty. Can you share any insight on whether migrating datetime/user-id to tx-data worth it?

misha10:09:14

Another question is: is there a recommended approach to describing content sharing? e.g. I am the author of the blog post, and I grant permission to read/modify it to these 3 users

robert-stuttaford10:09:33

hi @misha - can you describe what you mean by datetime/user-id ? do you mean linking the user who caused a transaction to occur, to that transaction - so, an audit trail?

misha10:09:28

@robert-stuttaford classic created-by created-datetime updated-datetime

misha11:09:14

in my case, the entity being created/edited is private/individual in a sense of "ownership", where only 2 use cases of transactions are possible: 1. the same user updates his own data. 2. some other user might update the data, if he is a collaborator (this is where my 2nd question origins). but for the sake of 1st use case only: if I need to mark an entity as belongs to user1, where do I put :entity/user-id: in entity data, or in tx data?

misha11:09:12

(from the "needs to be synchronized with datascript a lot" point of view, if that matters)

robert-stuttaford11:09:16

ok, gotcha. basically, you only need to do something for 'created-by'. the rest is discoverable already

robert-stuttaford11:09:47

when transacting something you want to track, you can link directly to the in-flight transaction's reified entity:

(d/transact conn [{<your entity here>} [:db/add #db/id[:db.part/tx] :transaction/responsible-user your-logged-in-user-id-here]])

robert-stuttaford11:09:23

what's nice about this is you can use it for lots of stuff. we do this for all txes performed by a logged in user.

robert-stuttaford11:09:42

however, you could also just make an attr that links the creating user directly to your entity

robert-stuttaford11:09:07

(d/transact conn [{<your entity here> :your-entity/created-by your-logged-in-user-id-here}])

misha11:09:10

@robert-stuttaford so you chose to go with user-id in tx-data? how often do you flush UI (datascript) data to server? Do you accumulate any period of txs at all (e.g. offline usage for minutes/hours)?

robert-stuttaford11:09:52

datascript syncs as early and as often as it can, but of course if you're offline for a long time, it'll only sync when it's back on

robert-stuttaford11:09:27

Nikita wrote a rad bi-di event source sync mechanism that can handle just about any amount of data, and batches events, etc

marshall13:09:13

that gives you approximate t values for the backups at a location

marshall13:09:29

which you can convert to wall clock time via the log

misha13:09:33

@robert-stuttaford but you keep individual tx-data intact, and send it to datomic? or attaching tx-data with user-id/date happens in back-end only, and datascript just sends something like data + cookies to infer the tx-data for datomic upon sync payload arrival?

misha13:09:50

I'd like to know if constructing tx-data on datascript side is viable, since I need: - client be able to work offline for days - still have correct timestamps on things in datomic (time of update, not time of sync) E.g. update thing on Monday, send it to Datomic on Friday, and on Saturday, as a result, be able to see that thing was updated on Monday by going to Datomic only (no help from datascript at this point)

robert-stuttaford13:09:02

@misha, we track client-side timestamps per-event (which is the source of truth for timing on those), and batch transact them

misha13:09:04

thank you