-
-
Notifications
You must be signed in to change notification settings - Fork 4.7k
Allow unified search results to have attributes #24474
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
Allow unified search results to have attributes #24474
Conversation
this one sounds good and flexible 👍 i have other places where i serialize data into one field. It works, but is useless overhead. |
|
I favor this over #24410 I am now unsure, if we first want to test this with e.g. Deck @juliushaertl and Deck app (@stefan-niedermann) or if we assume that this is flexible enough to handle everything (and that they how we do it, is ok). |
juliusknorr
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems reasonable 👍
|
@ChristophWurst Mind to rebase and squash? |
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
45ab58f to
885dabb
Compare
|
🤖 beep boop beep 🤖 Here are the logs for the failed build: Status of 156: failuremysql8.0-php7.4Show full log |
This is the result of a bit of discussion about #24410 with @tobiasKaminsky and affectively an alternative solution. In the first PR we settled with an extension of the API so that each result entry can have a
typeand aobject IDas that seemed generic enough. Now we discussed whether file search results should use the file ID, the remote file ID or the remote path for the ID. This lead me to the idea that we may want to be more flexible, as in allow each result to have any arbitrary number of attributes. Then we can put type, IDs and anything else there. The API is restrictive enough to only allow strings. Also if you use a composite key (Deck card on a specific board for example) you can now specify the key with two attributes and don't have to serialize it into the single field of the other PR.@blizzz @MorrisJobke @nickvergessen @rullzer what do you think? Which solution would you prefer?
I'd summarize that #24410 is more restrictive and this one more adaptable for future changes and adding more than one way to identify an object – files could specify all three of the IDs mentioned above and the clients use whatever is most convenient for them.