@madduci @Lilith

Das ist im wesentlichen #elasticsearch und das ist eine Verpackung aka UI um #lucene

@Lilith

#solr und #lucene gibt es schon im wesentlichen seit 2004.

Speaking of performance, I knew my plugin wouldn't be fast for any large repo - variously it indexed the repo into lucene then walked different branches to find containment. It's been to long for me to be specific about O-ness but it was definitely viable for small repos.

#jira #git #lucene

@parttimenerd That's an interesting approach, thanks a lot for sharing!

I also toyed with a similar idea a while back: https://binjr.eu/blog/2023/08/new-data-adapter-jdk-flight-recorder/
With that said, there are some differences in the approach I took over the one you discussed in your post.
For one, I opted to use an inverted index (#Lucene) instead of a relational DB as my backend, which comes with it's own trade-offs, like offering a query language that is somewhat easier to use, but not as nearly as powerful.
The other main difference, is that the route I used to get there is kinda like the opposite from the one you took: while you went from the backend working your way up to the UI, I very much started there (as I already had it) and worked my way down.
Doing things this way around meant that I could benefit immediately from the UI features that were there already (which was the whole point, of course) but it makes integrating new ones that don't fit so naturally with the rest of the tool, much more time consuming...

At any rate, I would love to hear your thoughts if you find the time to give it a try!
(you can get it here: https://github.com/binjr/binjr/releases)