This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (7)
- # babashka (1)
- # beginners (87)
- # boot (1)
- # cider (1)
- # clj-kondo (33)
- # cljfx (1)
- # cljs-dev (8)
- # clojars (3)
- # clojure (105)
- # clojure-austin (3)
- # clojure-europe (74)
- # clojure-finland (1)
- # clojure-korea (4)
- # clojure-nl (1)
- # clojure-uk (6)
- # clojurescript (10)
- # conjure (9)
- # cursive (29)
- # datalog (6)
- # datomic (13)
- # emacs (3)
- # events (4)
- # figwheel-main (1)
- # gratitude (1)
- # humbleui (6)
- # introduce-yourself (7)
- # jackdaw (1)
- # jobs (1)
- # lsp (29)
- # malli (3)
- # nbb (2)
- # podcasts (1)
- # portal (5)
- # re-frame (4)
- # reitit (28)
- # remote-jobs (5)
- # shadow-cljs (38)
- # tools-deps (46)
- # vim (6)
- # xtdb (24)
I haven’t done releases (just use git sha) but there’s some recent updates to xtdb-inspector https://github.com/tatut/xtdb-inspector#changes (UI convenience improvements, like filtering and ordering attributes page and minor fixes)
Thanks for sharing! It's great to see it evolve 🙂 Out of interest, has your work here influenced the requirements/development for https://github.com/tatut/ripley at all? Or are your other projects using Ripley much bigger & more advanced?
it has, I recently did maintenance work on ripley as well… mainly under the hood how it handles dynamic collections
so far I have 2 ripley projects “in production”, xtdb inspector which me and my coworkers use daily and the lipo portal
perhaps hyperfiddle photon will be the next big thing for web UI dev, but it isn’t here yet
> but it isn’t here yet I'd be interested in hearing more about why you think this.
Photon isn't GA yet, but I've got a copy and can confirm it's very real and promising 🙂
Just gave xtdb-inspector a quick whirl. Very useful, thanks, @U11SJ6Q0K! Initial observations:
• Perhaps it is my ignorance, but I thought "returns a ring handler" from readme meant I needed to integrate the handler/routes into the project's existing service. Instead,
xtdb-inspector.core/start starts a standalone server. Hence, it is actually very simple to add the inspector to a project.
• Everything seems to work as expected! One exception: doc history and links from other documents sections don't seem to refresh automatically.
• Would be convenient if
/doc listed, say, the last 50 modified docs (and their contents), instead of showing an empty doc.
• Would be convenient to have a list of most recent transactions and their ops.
Again, great work and thanks!
good ideas, a transactions page showing N last tx would be good and we can get that from the log
thanks for the ideas @U02E9K53C9L, I made a first draft of a tx page https://twitter.com/tatut/status/1541481064052432903 still could be improved but it’s a start
I'm trying to use
tx/register-index! and I think that my function that I pass there doesn't fire. Do I need some additional configuration?
I found that I could reuse the parameter from this line: https://github.com/xtdb/xtdb/blob/master/modules/lucene/src/xtdb/lucene.clj#L354 But now I cause a cyclic dependency. Is this what I need to use?
Quite possibly 🙂 if you are able to share some more of the code in your module it would help
I'm surprised there would be a cycle though, if you are merely copy-pasting from how xtdb-lucene does things. Do you have xtdb-lucene wired in at the same time?
As a follow-up for any curious readers, Martynas and I ended up speaking on a call which is when realised that the use-case and integration here is pretty different from Lucene. Like there's really a fully independent node (not a secondary index), so the wiring looks rather different(!)
In any way the initialization of the index would need to come before the main node comes up but then it doesn't work if the node is already started. The line from my message above forces the DI library to first start own secondary indices and only then start the main node. Which means that the cycle exists because I first expected to create the main node and then wanted to use the index. Also using the index post-a-priori will not work as the call will be ignored (actually it would be better if it would crash instead of being silent). So the only option is to first create the secondary node and only then proceed with the main node.