Hi, do you know what the document looks like? Does it have a value for :crux.db/id ?

You should at least be able to retrieve the document from the tx-log

If you forgot to add an ID then your confusion that may be the result of a small regression introduced in the last release, that's now fixed on master https://github.com/juxt/crux/commit/3d186a7773f4ecbe2e402b6c6bf9e77e6646cb82 discussed in the last few days in this channel history

Thanks for the quick answer - could you give me an example of how get documents from the tx-log?

You can find the transaction that is showing committed but that you can't retrieve with open-tx-log, like this for example (take 3 (iterator-seq (crux/open-tx-log adb/conn 40 true)))

https://opencrux.com/docs#_tx_log

Scroll up to the chat on Thursday, May 14th, for discussion on how to fix the document if the problem is that it doesn't have a crux.db/id key.

Thanks Eric, I know the id, but it does not get returned when I do the entity check.

and tx-committed? return true

Are you using await-tx before checking? Or is this in the repl?

Crux' indexes don't currently support variables in the attribute positions of triple clauses. The main justification being that in the vast majority of use-cases all attributes will be known ahead of time, but the benefits are significant in simplifying the query algorithm and minimising disk space. Therefore for certain inference-heavy domain use-cases Crux is probably not appropriate as things stand today. A workaround for doing ad-hoc exploration of data with the current functionality is to look at attribute-stats and generate queries based on that (though they may be slow!) We may well (optionally) support variable attributes in a future release but we have no immediate plans.

I hope that makes sense, but I would be keen to hear about your use-case anyway 🙂

^ This is something I also tried once I started playing around with code, after having gone through the tutorials. I scanned the docs to confirm it wasn't supposed to work and never saw anything. Just another anecdotal data point for what newcomers experience.

Being able to get the attribute names associated with the data allows for creating table heading in UI and reports etc, without having to know them in advance.

Linked with this I would like to know how to optionally return a value if it exists but nothing if it does not

Or set a default when it does not exist

Can getting the attribute names without knowing them in advance be done some other way? If you know the type of thing that you you want to report on, then you must know one of it's attributes. Since there are no "tables" you can't really use database introspection to dynamically get the names of columns of a table. It's not like you have a "user" table and a "cars" table, each with different columns. Each object that you model is defined by its attributes. So if you want to report on something, you must know at least the attribute that identifies what "type" it is. You could give each entity a "type" attribute. Then you don't need to know the other attributes ahead of time. You could write some shared reporting code that given a type would get all entities that have :data/type :user or :data/type :car and then generate column headers for your UI based on the set of attributes of each collection

And {:find [s p o] :where [[s p o]]} would just return everything, yeah? Every entity must have a crux.db/id key, so that's almost the same thing as {:find [s] :where [[s :crux.db/id o]] :full-results? true} and then just getting the entity/attribute/value triplets from each result.

Vars in attribute position not being supported is mentioned here, but it isn't very prominent https://opencrux.com/docs#queries_datascript_differences

Thanks you all