Fork me on GitHub
#crux
<
2020-07-24
>
plexus08:07:00

Just found out today there's a Rust client for Crux. Not sure it's been mentioned, seems it's pretty new https://github.com/naomijub/transistor

👍 2
sveri12:07:39

So, what's the idiomatic way to distinct different types in crux? Do you add just something like :ns/type :pet or :ns/type :user to your entities? Or is there something I am missing?

jarohen12:07:01

Yes, this is perfectly valid 🙂

sveri12:07:28

Awesome, thank you

Jorin12:07:03

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?

sveri12:07:45

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).

sveri12:07:42

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

Jorin12:07:20

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 :)

sveri12:07:04

Yea, that's true too.

sveri12:07:51

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

quadron13:07:31

how do i return all the attributes for an entity in a single query? something like the following:

(crux/q (crux/db conn) '{:find [e *]
                           :where [[e :crux.db/id :foo]]})

jarohen13:07:23

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

jarohen13:07:09

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

jarohen19:07:29

Evening all! We've just pushed a release candidate for Crux 1.10 - "20.07-1.10.0-beta-SNAPSHOT". * SQL module (using Apache Calcite): you can now also query Crux using SQL! (https://github.com/juxt/crux/tree/master/crux-sql) * Speculative queries: what would happen if these documents were transacted? (https://github.com/juxt/crux/blob/master/docs/speculative.adoc) * More types of entity ids - particularly, strings and integers. This one will involve an index version bump - if you haven't already upgraded your production systems to 1.9.0 it might be best at this point to wait for 1.10.0. * EQL Projections (aka 'pull syntax'): returning nested tree structures from queries in addition to flat tuples (https://github.com/juxt/crux/blob/master/docs/projections.adoc) * Removing polling: you can now plug in non-polling transaction logs (https://github.com/juxt/crux/pull/969), and await-tx no longer polls either (https://github.com/juxt/crux/issues/825). For all the issues/PRs in 1.10.0, take a look at the Github milestone: https://github.com/juxt/crux/milestone/14?closed=1 All being well, we're aiming to cut the release (including a fuller set of release notes) early next week. In the meantime, if any of you are able to give this a quick road-test and let us know of any issues - either on here, via our official Zulip support channel (https://juxt-oss.zulipchat.com/#narrow/stream/194466-crux) or <mailto:[email protected]|[email protected]> - that'd be great! Have a great weekend 🙂

🙏 1
🔥 2
lgessler15:07:14

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?

jarohen16:07:42

🙂 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! 🙂

sveri20:07:11

I am trying to reference entities via uuid. put and /entity work fine, but whenever I try to delete: {:crux.tx/delete #uuid 0c9fd9dc-0a53-46f6-8301-18b6a49174d6} or {:crux.tx/delete 0c9fd9dc-0a53-46f6-8301-18b6a49174d6} I get an error that my uuid is an invalid number. Also, is there a way to delete everything that is found by :where?

jarohen20:07:15

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

jarohen20:07:05

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

jarohen20:07:04

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

sveri21:07:25

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 🙂

🙂 1
sveri20:07:41

I see that delete, needs a time, so I tried crux.tx/evict but I get the same error.

jarohen20:07:30

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.

sveri20:07:39

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.

sveri21:07:38

Btw. I love all the work you put into the documentation, besides crux itself. It's awesome.

🙏 3