This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-08-27
Channels
- # admin-announcements (1)
- # announcements (11)
- # babashka (17)
- # beginners (26)
- # calva (6)
- # cider (2)
- # circleci (1)
- # clojure (41)
- # clojure-dev (1)
- # clojure-europe (31)
- # clojure-france (2)
- # clojure-italy (10)
- # clojure-nl (7)
- # clojure-norway (5)
- # clojure-spec (15)
- # clojure-uk (42)
- # clojurescript (4)
- # code-reviews (12)
- # conjure (10)
- # datalog (2)
- # datascript (15)
- # datomic (37)
- # emacs (1)
- # events (5)
- # fulcro (19)
- # jobs (1)
- # jobs-discuss (9)
- # kaocha (2)
- # luminus (14)
- # meander (4)
- # membrane (39)
- # off-topic (26)
- # other-languages (2)
- # re-frame (13)
- # reitit (6)
- # rewrite-clj (39)
- # sci (6)
- # shadow-cljs (33)
- # test-check (15)
- # vrac (17)
- # xtdb (7)
One question regarding eviction and deletion of (old) data. Let's say, that our complete dataset will evolve through time, is there a way to set some kind of TTL for documents which have new versions. The following rule is what I'm looking at:
delete all invalid documents older than <date>. // invalid documents - documents which have new versions with higher valid date
Or maybe something like this:
automatically delete invalid documents which already have <n> new versions
The thing is, that if "schema" is evolving, the storage required can grow fast and we would like to have a mechanism to handle this. Is this something what can we expect from Crux to offer, or should we manually handle this by our own logic?We did some exploration in this space earlier in the year, driven by client requirements. A PR came very close to being merged into master, but we decided against merging in the end, mainly because client requirements changed and we weren't eager to support the functionality (vs all the other important things on the roadmap). So it's definitely possible to do something sensible, and maybe you could resurrect this without too much trouble (or we could help π ): https://github.com/juxt/crux/pull/727
Well, this is definitely something worth taking a look into. If we decide to go with Crux, I could resurrect this PR for sure. We would end up coding it anyways sooner or later.
Cool, I'd be happy to chat sometime about requirements and what we considered and what we didn't yet try
We are currently in the "proof of concept" phase to be able to use Crux for our project. I'm working on this and at the moment looks very promising. The list requirements is still not final. And I'd be glad to discuss them with you once we have the final picture. I'll keep you posted. In the meantime and I may came up with more (dummy) questions.
Hi, I've been digging into Crux sources because I wanted to understand more about the KV store (I'm trying to see if I can extend it to MongoDB, maybe just for fun π), but I keep finding myself quite lost on the source. Can I send my questions here, on a thread?
For example, the API for store
receive lots of UnsafeBuffer
, but I have no idea what do do with their contents, or even if they should be treated as implementation details, etc...
Hey @mauricio.szabo - yep, definitely happy to answer these kind of questions π We've recently opened up a crux-dev channel over on our Zulip for people more interested in how Crux works, and how to extend it - https://juxt-oss.zulipchat.com/#narrow/stream/251593-crux-dev (we tend to find Zulip easier than Slack to keep track when there're a few different longer threads going on!)