I'm trying to write a transaction function that links two entities together via a :ref, but one or both of the entities may not already exist in the db at the time this runs. I was hoping the upsert behavior would allow me to ignore whether they exist or not, but I'm getting

java.util.concurrent.ExecutionException: java.lang.IllegalArgumentException: :db.error/not-an-entity Unable to resolve entity:

if I can't abstract over entity existence, what's the idiomatic way to check if the target entity existed from the result of a pull expression?

you just can't use lookup refs

but you can do e.g. [[:db/add "e1" :ident1 "id1"] [:db/add "e2" :ident2 "id2"] [:db/add "e1" :ref "e2"]]

so basically those first two are just setting up temp ids?

or even [{:ident1 "id3" :ref {:ident2 "id4"}}]?? 🙂

right. in the old days we would've had to pick a partition there for each entity

sorry, the :ident1 stuff is throwing me a bit

[{:db/ident :ident1
  :db/cardinality :db.cardinality/one
  :db/valueType :db.type/string
  :db/unique :db.unique/identity}
 {:db/ident :ident2
  :db/cardinality :db.cardinality/one
  :db/valueType :db.type/string
  :db/unique :db.unique/identity}
 {:db/ident :ref
  :db/cardinality :db.cardinality/one
  :db/valueType :db.type/ref}]

those would be the identity/unique val?

got it

that's interesting. I wonder if there's a technical reason why lookup refs can't work in this case.

I wanted to do it that way so the tx fn could accept anything valid to identify an entity, so I guess lookup ref or entity id at this point, and pass it through to Datomic without introspecting to figure out which type it was

given the existence of the "default partition" (and lack of partitions in cloud) it would seem reasonable to me

maybe just a "not yet implemented" on that one

ro6: I’ve always wished idents would eval to temp ids as well as entity ids, would be really cool

there’s a case where the semantics might be confusing though (imo)

what's that? I haven't thought deeply about it

[[:db/retract [:ident1 "thing"] :ident1 "thing"] 
{:thing1 "thing" .. other stuff ..}
{:thing1 "other" :ref [:ident1 "thing"]}]

currently, that ref would always point to the “old” thing

hm, I'll have to stare at that later...

What do I miss out on when if I use cloud Datomic. I'm aware of: 1. No excision 2. No backup/restore 3. Lambda cold starts (> 10 seconds) What else could be a pain point? I'm not trying to be negative. Everything is a tradeoff. I just want to go in with my eyes open.

Nothing in the Peer library that isn't also in the Client lib, so the entity api and multi-database queries

The cold start thing is surmountable. In the early stages you can just hit the endpoint periodically to keep it warm (I actually have an endpoint called /keep-warm), and I think they are working on a direct link from API Gateway to the EC2 instances that would bypass Lambda, and make $ sense as you scale.

I really like the lambda idea, but I think a lot of the slowdown is because the lambda is inside the VPC. could be wrong

true, I've read that

takes it from 2 sec to 15 or so maybe

I guess we can cross our fingers that AWS helps ameliorate the cold start time in a VPC. the security model of datomic makes it hard to do anything else