what's an example of when you'd want to use a :db.unique/value instead of a :db.unique/identity?

"Unique values have the same semantics as unique identities, with one critical difference: Attempts to assert a new tempid with a unique value already in the database will cause an IllegalStateException."

http://docs.datomic.com/identity.html#unique-values

yep, read the docs 🙂 just trying to figure out the intended use case.

new question: if you d/delete-database a db with underlying sql storage, does it drop the associated rows in sql?

No. That happens when you run gc-deleted-databases

you mean gc-storage?

haven't run that yet. good idea to run it on some regular schedule i assume?

http://docs.datomic.com/capacity.html#garbage-collection-deleted-production

No gc storage is for active dbs

ah, command line api. i was looking at the clojure api

thanks, good stuff

right but having a hard time thinking of a use case

if you had an entity that was totally immutable (never updated)

then you wouldn’t want to upsert it, devth

sure.

so i take it ppl use identity more often?

i.e. unless you have a special reason to use value, default to using identity

that’s probably fair

i would say unless you know you’re going to upsert, just use value, schema change allows those attributes to change later anyways

oh, i thought that was unalterable

say I want to add a derived field to a reference, and there are many of this type in the system (memory large). Let’s call the ref a location, cause that happens to be what I’m updating currently. In a transaction function, I could query all locations and then map over and return the new datom for each. If I didn’t want to pull all results in to memory at once, what would i do? Also, if I do this within a transaction function the size of the returned transaction would be enormous. I should probably fix that as well, no?

I should probably do this outside of a transaction function, and use d/datoms, shouldn’t i?

"add a derived field to a reference" means what?

I'm not clear what you're querying and transacting

are you trying to compute some extra attribute+value on an entity based on input from a query, and do it in bulk across a bunch of entities?

I’m just adding a new attribute to an entity in the system, and there are a lot of entities I need to update. For each new attribute is a projection of many existing attribute on said entity. I think the answer to your last question is, yes. @favila

why are you desiring a transaction function?

no, reason. I realized that was not a good direction

my guess is I should use d/datoms to iterate over all the entities and then tx-pipeline them in

options are: 1. don't transact. if purely a derived value, just have the peer derive it as needed. 2. transact derived and non-derived together 3. transact derived separately later (possibly in bulk; be careful that entity hasn't changed in a way that invalidates the derived value).

you can't use a transaction function for derived values because these cannot see the result of the transaction they are within.