Search Bar for Issues and Pull Requests #121

New Issue

GiteaMirror · 2025-11-02T03:09:52-06:00

GiteaMirror commented

2025-11-02 03:09:52 -06:00

Originally created by @ethantkoenig on GitHub (Dec 13, 2016).

Add a search bar for searching issues and pull requests. This would be similar to Github's search bar.

I would be happy to implement this proposal, but just want to make sure there is interest before doing so.

Originally created by @ethantkoenig on GitHub (Dec 13, 2016). Add a search bar for searching issues and pull requests. This would be similar to Github's search bar. I would be happy to implement this proposal, but just want to make sure there is interest before doing so.

GiteaMirror added the type/feature type/enhancement labels 2025-11-02 03:09:52 -06:00

GiteaMirror closed this issue

2025-11-02 03:09:52 -06:00

GiteaMirror commented

2025-11-02 03:09:53 -06:00

@bkcsoft commented on GitHub (Dec 13, 2016):

Fire at will 😄

@bkcsoft commented on GitHub (Dec 13, 2016): Fire at will 😄

GiteaMirror commented

2025-11-02 03:09:53 -06:00

@tboerger commented on GitHub (Dec 13, 2016):

Makes sense for sure, but I'm also sure we need some kind of indexer or cache layer.

@tboerger commented on GitHub (Dec 13, 2016): Makes sense for sure, but I'm also sure we need some kind of indexer or cache layer.

GiteaMirror commented

2025-11-02 03:09:53 -06:00

@lunny commented on GitHub (Dec 13, 2016):

@tboerger, indexer could be put in 1.x.x, we could implement it use database like as a short term solution.

@lunny commented on GitHub (Dec 13, 2016): @tboerger, indexer could be put in 1.x.x, we could implement it use database `like` as a short term solution.

GiteaMirror commented

2025-11-02 03:09:54 -06:00

@tboerger commented on GitHub (Dec 13, 2016):

@lunny the only think in the database are issues. For choose search you are forced to search within the repo.

@tboerger commented on GitHub (Dec 13, 2016): @lunny the only think in the database are issues. For choose search you are forced to search within the repo.

GiteaMirror commented

2025-11-02 03:09:54 -06:00

@ethantkoenig commented on GitHub (Dec 15, 2016):

I looked into using a full-text-index to speed up searches, specifically for Postgres. Postgres has support for full-text-indices (docs), but they do not seem to interact with xorm well.

On calls to Sync2(..), xorm tries to delete any index that is not listed in the corresponding struct's definition (session.go, line 4091). The full-text-index is not listed in the struct's definition, so xorm tries to delete it.

Is there some way to get xorm to be okay with the full-text-index, particularly a way that will work for all supported RDBMSs? Any help would be appreciated 😃

@ethantkoenig commented on GitHub (Dec 15, 2016): I looked into using a full-text-index to speed up searches, specifically for Postgres. Postgres has support for full-text-indices ([docs](https://www.postgresql.org/docs/9.6/static/textsearch.html)), but they do not seem to interact with `xorm` well. On calls to `Sync2(..)`, `xorm` tries to delete any index that is not listed in the corresponding struct's definition (`session.go`, line 4091). The full-text-index is not listed in the struct's definition, so `xorm` tries to delete it. Is there some way to get `xorm` to be okay with the full-text-index, particularly a way that will work for all supported RDBMSs? Any help would be appreciated :smiley:

GiteaMirror commented

2025-11-02 03:09:54 -06:00

@lunny commented on GitHub (Dec 15, 2016):

But maybe not all the database support full-text-index? Another way is to store index ourself, and we can have a task called index which will index issue titles and contents, wiki title and contents and codes?

@lunny commented on GitHub (Dec 15, 2016): But maybe not all the database support full-text-index? Another way is to store index ourself, and we can have a task called index which will index issue titles and contents, wiki title and contents and codes?

GiteaMirror commented

2025-11-02 03:09:54 -06:00

@lunny commented on GitHub (Dec 15, 2016):

Maybe we can use http://www.blevesearch.com/ to do that.

@lunny commented on GitHub (Dec 15, 2016): Maybe we can use `http://www.blevesearch.com/` to do that.

GiteaMirror commented

2025-11-02 03:09:54 -06:00

@tboerger commented on GitHub (Dec 15, 2016):

I would also suggest a bleeve based index.

@tboerger commented on GitHub (Dec 15, 2016): I would also suggest a bleeve based index.

GiteaMirror commented

2025-11-02 03:09:55 -06:00

@ethantkoenig commented on GitHub (Dec 15, 2016):

I've begun looking into bleve. Just to double-check, the idea is to

maintain one bleve index per repository, and
during an issue search, issue both a SQL query (for other criteria) and a search on the index (for keyword), and then intersect the two results?

Let know me if I'm missing something.

@ethantkoenig commented on GitHub (Dec 15, 2016): I've begun looking into bleve. Just to double-check, the idea is to - maintain one bleve index per repository, and - during an issue search, issue both a SQL query (for other criteria) and a search on the index (for keyword), and then intersect the two results? Let know me if I'm missing something.

GiteaMirror commented

2025-11-02 03:09:55 -06:00

@lunny commented on GitHub (Dec 16, 2016):

If we use bleve, SQL query will be no need. I think one repo one index file is not good idea. I prefer one function one index. So that issue/pr index, repo index, wiki index. And in fact this work's emphasis is splitting words in different languages or mixed languages.

@lunny commented on GitHub (Dec 16, 2016): If we use bleve, SQL query will be no need. I think one repo one index file is not good idea. I prefer one function one index. So that issue/pr index, repo index, wiki index. And in fact this work's emphasis is splitting words in different languages or mixed languages.

GiteaMirror commented

2025-11-02 03:09:55 -06:00

@ethantkoenig commented on GitHub (Dec 16, 2016):

If we don't have a SQL query, how can we support existing filters like tags, or issues created by a particular user?

@ethantkoenig commented on GitHub (Dec 16, 2016): If we don't have a SQL query, how can we support existing filters like tags, or issues created by a particular user?

GiteaMirror referenced this issue

2025-11-02 11:40:18 -06:00

[PR #121] [MERGED] Last Login for admin manage your users #15163

GiteaMirror referenced this issue

2025-11-02 15:31:48 -06:00

[PR #5334] [MERGED] Add raw blob endpoint to get objects by SHA ID #17756

Sign in to join this conversation.