Fork me on GitHub

is there anything I should do in order to force Datomic to remove the data from storage after delete-database?


I’m on Postgres… I guess given all the Datomic databases are in the same table - I have to vacuum full the table in order to reclaim the space - is that right?


The new pull grammar doesn’t seem to match what is demonstrated in the blog post.


Is attr-with-options allowed on a map key? Grammar says no, blog post says yes.


And what about default-expr on map keys? That doesn’t seem to be allowed either. Is it now allowed if we use attrs-with-options?


And finally, when is :ident-only going to be an attr option? 😏


@favila It should be allowed on map key - i may need to tweak the grammar


@favila :ident-only as an attr option is a great feature request - can you add it to the portal?


and yes, it looks like i need to tweak the map spec grammar - thanks for catching that

Oliver George23:12:28

I'm wondering what patterns people use to enforce data integrity constraints. I see that database functions can be used for integrity constraints. It looks like database functions must be intentionally triggered in the transaction meaning it's the obligation of the programmer to remember to fire the right constraint checks. What are the common implementation patterns? I can imagine (1) by convention trigger a common database function which will check all constraints. (2) use different database functions for different types of update so that relevant constraints are checked. (3) keep a list of constraints and associated attributes to decide what constraints need to be checked for a transaction.

Oliver George23:12:24

The simple use case I was exploring is: unique constraint across multiple attributes. (eg.