I tried to retract entity with

transacted payload [[:db.fn/retractEntity 13194139534407]]

java.util.concurrent.ExecutionException: java.lang.IllegalArgumentException: :db.error/reset-tx-instant You can set :db/txInstant only on the current transaction.

is that entity id a transaction id?

https://juxt.pro/blog/posts/datomic-packer-terraform.html

@podviaznikov You are attempting to retract a transaction id, but you are not allowed to alter the :db/txInstant assertion on transaction entities.

We’re beginning to write web service handlers around datomic, and I’m grappling with the question of where and how to enforce authorization. Do folk tend to e.g. write a predicate fn for a user and an arbitrary datomic transaction, or check authorization for specific mutations?

@donaldball I know some people use db filter with user-based predicate to enforce visiblity, but that is belt-and-suspenders

you really do need to design specific ops to be safe

(at least that is what we discovered)

an idea we had was post-validation: run the tx with a db/with, then validate no constraints were violated (data or security), then transact with a conditional to ensure integrity

we have not tried it yet at scale though

I've used a list of (prismatic) schemas to validate incoming transactions

it worked well but wasn't fine-grained (all admins can transact all transactions matching any whitelisted schema)

@donaldball we handle authorization on a per-operation basis.

(I should add that we don't provide our clients an expressive language à la GraphQL / Datomic Pull)

We’re anticipating using om.next, but as I understand it, the common path even there is for the client to send the server a named mutation operation with some arguments, so y’all’s advice is well taken. Thanks.

we handle authz by sanitizing incoming tx vectors and pull queries. (still WIP)

completely agnostic to the datomic schema / model, supports any number of roles, access groups and access rules.

Transactions are entities

Every transaction creates an entity

that is the ‘reified’ transaction itself

at a minimum, it contains the txInstant of that transaction

it can also have other attributes (transaction metadata)

as Francis mentioned, you can’t retract Transactions

if (d/part <entity-id>) is 3 (= :db.part/tx), then entity-id is a transaction

this is true of the entity id you posted

Hey @marshall or someone who can fix it: http://www.datomic.com/videos.html

The videos from Datomic Conf are not showing on that page

> Sorry, Because of its privacy settings, this video cannot be played here.

@marshall bah, it was due to my use of ghostery/privacy badger/adblock

ah. glad you got it figured out

the video content is stored elsewhere from the website

a lot of ad blockers prevent embedded video when it’s not from the same host

@marshall by any chance do you have links to the videos themselves (non-embedded)

i was unable to inspect and snag them from the page

i don’t think they’re available for local download

i was interested in linking to tim's video directly in another slack channel

but no big deal

yeah, looks like they’re only available on that page ATM

you know how a query for a set of entities will return them in form #{[eid1] [eid2]}? can the query be changed so that the result would simply be #{eid1 eid2}?

@devth http://docs.datomic.com/query.html#find-specifications

@favila thanks! was only familiar with the ?a . spec