Hi @UL638RXE2 👋 We tend to use in-memory XT instances for this (using (xt/start-node {})), and then throw it away at the end of the test. Our test fixture (assuming clojure.test) looks something like this:

(defn with-node [f]
  (with-open [node (xt/start-node {})]
    (binding [*api* node]
      (f))))

Ok thanks. That makes sense.

I changed it for now so that I check the query plan for which bindings are ids... but that doesn't help me when I'm rendering pulled data, I'd still like to show if something is id in that case as well (to link to the doc page)

I'm guessing something from the xtdb.index ns, investigating that now

are you using (some? (xt/entity db value)) inside of an open-db?

that's not the most efficient option though, as the entity fn retrieves the entire document (potentially even hitting the doc store if the document cache is small). How about doing (some? (ffirst (xt/q db {:find [e] :where [[e :xt/id]]}))) inside an open-db? Once the initial query plan gets cached, I wouldn't expect any internal API to be faster than using that

thanks, that looks good... basically I just want to check that a doc exists and the xt/entity was returning too much

congrats on shipping the inspector, btw! Somehow I only just put 2+2 together and saw you also created ripley?! That's really awesome 😃 I am personally very excited about building local apps with a really dumb (web) UI, where latency isn't an issue and ripley might be the best bet. Would you be up for a chat later next week? Mind if I DM you?

thanks, sure

it would be interesting to see ripley used by others

hmm, I seem to be getting very scary JVM crashes with this id checking query

---------------  T H R E A D  ---------------

Current thread (0x00007fd6faae3a00):  JavaThread "clojure-agent-send-off-pool-5" [_thread_in_native, id=46863, stack(0x0000700007140000,0x0000700007240000)]

Stack: [0x0000700007140000,0x0000700007240000],  sp=0x000070000723e110,  free space=1016k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [liblwjgl_lmdb.dylib+0xd5f3]
[error occurred during error reporting (printing native stack), id 0xe0000000, Internal Error (src/hotspot/os/bsd/decoder_machO.hpp:43)]

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
J 7031  org.lwjgl.util.lmdb.LMDB.nmdb_cursor_open(JIJ)I (0 bytes) @ 0x00000001228eb9ef [0x00000001228eb9a0+0x000000000000004f]
J 7030 c1 org.lwjgl.util.lmdb.LMDB.mdb_cursor_open(JILorg/lwjgl/PointerBuffer;)I (26 bytes) @ 0x000000011b95d71c [0x000000011b95d3a0+0x000000000000037c]
J 7029 c1 xtdb.lmdb$new_cursor.invokeStatic(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object; (120 bytes) @ 0x000000011b952a44 [0x000000011b951ec0+0x0000000000000b84]
J 7028 c1 xtdb.lmdb$new_cursor.invoke(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object; (10 bytes) @ 0x000000011b951a34 [0x000000011b9519c0+0x0000000000000074]
J 6956 c1 xtdb.lmdb.LMDBKvSnapshot.new_iterator()Ljava/lang/Object; (65 bytes) @ 0x000000011b9210fc [0x000000011b920c00+0x00000000000004fc]
J 8964 c1 xtdb.kv.index_store$new_kv_index_snapshot$fn__10633.invoke()Ljava/lang/Object; (59 bytes) @ 0x000000011b36707c [0x000000011b366a20+0x000000000000065c]
J 4251 c2 clojure.lang.Delay.deref()Ljava/lang/Object; (75 bytes) @ 0x0000000122608184 [0x00000001226080a0+0x00000000000000e4]
J 8229 c2 xtdb.query$new_binary_index$fn__42198.invoke(Ljava/lang/Object;)Ljava/lang/Object; (68 bytes) @ 0x00000001229a2520 [0x00000001229a2300+0x0000000000000220]
J 8116 c2 xtdb.index.SeekFnIndex.seek_values(Ljava/lang/Object;)Ljava/lang/Object; (113 bytes) @ 0x00000001229324e0 [0x0000000122932440+0x00000000000000a0]
J 8373 c2 xtdb.index.DerefIndex.seek_values(Ljava/lang/Object;)Ljava/lang/Object; (67 bytes) @ 0x00000001229ca8d0 [0x00000001229ca820+0x00000000000000b0]
J 8784 c2 xtdb.index.NAryJoinLayeredVirtualIndex.seek_values(Ljava/lang/Object;)Ljava/lang/Object; (209 bytes) @ 0x0000000122a18990 [0x0000000122a188a0+0x00000000000000f0]
J 8373 c2 xtdb.index.DerefIndex.seek_values(Ljava/lang/Object;)Ljava/lang/Object; (67 bytes) @ 0x00000001229ca8d0 [0x00000001229ca820+0x00000000000000b0]
j  xtdb.index.UnaryJoinVirtualIndex$fn__40891.invoke()Ljava/lang/Object;+94
j  xtdb.index.UnaryJoinVirtualIndex.seek_values(Ljava/lang/Object;)Ljava/lang/Object;+17
J 8784 c2 xtdb.index.NAryJoinLayeredVirtualIndex.seek_values(Ljava/lang/Object;)Ljava/lang/Object; (209 bytes) @ 0x0000000122a18990 [0x0000000122a188a0+0x00000000000000f0]
J 8806 c2 xtdb.index$layered_idx__GT_seq$step__40939.invokePrim(Ljava/lang/Object;JLjava/lang/Object;)Ljava/lang/Object; (446 bytes) @ 0x00000001225eba58 [0x00000001225eb0e0+0x0000000000000978]
J 8201 c2 xtdb.index$layered_idx__GT_seq$step__40939.invoke(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object; (16 bytes) @ 0x00000001229922e4 [0x00000001229922a0+0x0000000000000044]
j  xtdb.index$layered_idx__GT_seq.invokeStatic(Ljava/lang/Object;)Ljava/lang/Object;+126

...

I'll try to investigate what value is actually causing this

actually, nevermind... that is user error. I was doing it in another thread and using with-open... that was not correct, as we discussed in the other thread

Thanks for following up & glad you figured it out!