Yes, this is perfectly valid 🙂

Awesome, thank you

In a majority of use cases we might have to map to explicit types, also in Crux. But for certain systems we build from scratch there is also the option to build them in such a way, you never have to explicitly differentiate between types: If all attributes are namespaced and unique, you might not need any explicit types. So if you want all "users" you would instead query for all objects that have an attribute :my-user/id or even more specific attributes. Does that make sense?

Yea, that makes sense. It's just, that in my case, types are user dependent, so the namespace would be a combination of user id and user defined type. which would be the same like having to entries in the data map (user id and type).

I think the first option would be half a lie, as the ns in reality never exists as clojure namespace.

As far as I understood key namespaces really don't have to map to Clojure namespaces and some people criticize that the shorthand ::key syntax is confusing because it gives the impression that they belong together. I don't have a strong opinion on this, but I can definitely see how it can be useful to have keys in namespaces which are not related to the namespaces in the code base :)

Yea, that's true too.

but, there is another point that just occured to me. having a user belonging id as part of a key would make it hard to adapt the data later if the user id changes

Hey @UA2JG2Y11 🙂 you can use the entity API for this - (crux/entity db :foo)

I'm afraid we don't support wildcard attributes within queries - we don't keep sufficient indexes to make it performant as yet, although this might change in the future

thx

really excited about the SQL support and EQL pull support! I hadn't heard about EQL being supported in crux before this--this is totally new, right? to what extent is the rest of EQL supported?

🙂 glad to hear it! We're supporting a subset of the query language as a first pass - unions and recursive queries aren't included as yet but will likely come later. Mutations may well be a bit longer as they don't translate directly into Crux transaction operations - we'll want to consider those carefully before we commit to an API. Hopefully this is plenty to get people started though! 🙂

Hey Sven - you'll need to double-quote the UUID - [:crux.tx/delete #uuid "..."]

re deleting everything found by :where - the safest way is with transaction functions. These can run queries, and they're expected to return a list of transaction operations - so you can turn the result of the query into a list of deletes

Ah, sorry, I hadn't spotted that you're using a map above - Crux expects a vector for transaction operations

Thanks, I finally got it. Used the query endpoint instead of tx-log -.- Also the map instead of the vec of vecs. It works now 🙂

Delete doesn't necessarily need a time - if you don't provide one, it defaults to the current time. Evict's really only for the case where you have to irretrievably remove data from Crux - we recommend delete for all other use cases, to preserve the audit history.

Yea, that makes sense. It's just, no matter what combination of evict / delete I try, it just won't work. Btw. I am using the REST Api for that.