@tony.kay perhaps you already went over this but why not use uuids (or squuids) generated client side rather than :db/id
s, 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.