@tony.kay perhaps you already went over this but why not use uuids (or squuids) generated client side rather than :db/ids, that way you wouldn’t have to deal with tempids at all right?

@currentoor you can do that if you want, the id translation is optional, mostly to deal with systems where using UUID's is not feasible

@wilkerlucio if you don’t mind me asking, where would UUID’s not be feasible?

for example working with a legacy database, and you want/need to keep the existing db ids

still not sure why that would make it necessary, you could easily add UUID attributes retroactively no?

also, AFAIK @tony.kay was not dealing with a legacy database when he built untangled

@currentoor but tempids are not an untangled thing, it is an Om.next thing, and given that people still want to do that, therefore there is the support for it, I have used this myself dealing with legacy databases on a project

deciding to use UUID's across the system is a design decision, I think we don't want to enforce that on people

Untangled just add's some plumbing to make it even easier

makes sense?

yeah, i suppose that’s fair, i’ve been using the tempid feature in untangled for about a year now

i used it just because it was there in the examples

but now i’m starting to think, maybe i should have just used uuid’s from the start

for example tracking the creation/deletion of an entity in our analytics software is easier when you don’t have a tempid

and having multiple paths in our URL routes (one for db/id and one for tempid)

Hey folks, are there any problems with querying an ident from a component that itself is backed by that same ident? This is not a recursive query, rather a different query over the same backing ident.