Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement project search #10

Open
ddsnowboard opened this issue Mar 20, 2019 · 3 comments
Open

Implement project search #10

ddsnowboard opened this issue Mar 20, 2019 · 3 comments
Assignees
Labels
enhancement New feature or request

Comments

@ddsnowboard
Copy link
Collaborator

ddsnowboard commented Mar 20, 2019

From the spec:

Project Search
A section where any member can search projects based on keyword, title, organization, or class. Whenever a search is being performed, the searcher also must satisfy the project statuses they are searching for: open/unassigned (unstarted or paused), in-progress, completed. This defaults to open.

Keywords, nota bene, are in a separate table, which I missed at first, and the project.description column should probably also be included. Since we'll be searching user-generated text for instances of other user-generated text, we'll probably want to use Postgres's super full-featured full-text search. It's somewhat complicated (so much so, in fact, that we might be able to pass it off as an advanced feature), but it's incredibly powerful, so I think it might be worth it.

At the time of this writing, the status row of projects, the referent of the last part of the quoted paragraph, is just an integer in the database. This should probably be changed to an enum at some point (#16), but a question remains as to when. I wouldn't go so far as to say that this ticket should be blocked on that change, but the current arrangement certainly adds complexity to a feature that is already plenty complex.

Another question (which I pose to all collaborators) is whether the design work on this feature should be done as part of this ticket or separately. If this does contain the visual part, that will simplify things somewhat, but it will also be a much larger task, one which might be difficult or impossible for a single person to do adequately.

@ddsnowboard ddsnowboard added the enhancement New feature or request label Mar 20, 2019
@ddsnowboard
Copy link
Collaborator Author

Correction: because of time constraints, we're going to first implement basic text search (basically using LIKE) and then later use full-text searching.

@ddsnowboard ddsnowboard self-assigned this Mar 22, 2019
@ddsnowboard ddsnowboard mentioned this issue Mar 25, 2019
@ddsnowboard
Copy link
Collaborator Author

We still have to implement full-text search

@ddsnowboard ddsnowboard reopened this Apr 1, 2019
@tamaraniac tamaraniac added demo 2 and removed demo 2 labels Apr 6, 2019
@tamaraniac
Copy link
Collaborator

"One of the queries must involve join of multiple (at least 2) tables." is really the only requirement we need for the demo 2 search, and with the way our tags are stored separately, I believe we already fulfill this. If you really want full-text search though, go for it.

@rjaltman rjaltman added this to the Demonstration Two milestone Apr 9, 2019
@tamaraniac tamaraniac removed this from the Demonstration Two milestone Apr 14, 2019
@tamaraniac tamaraniac removed the demo 2 label Apr 14, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants