You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
Correction: because of time constraints, we're going to first implement basic text search (basically using LIKE) and then later use full-text searching.
"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.
From the spec:
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.
The text was updated successfully, but these errors were encountered: