-
-
Notifications
You must be signed in to change notification settings - Fork 317
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
API support for storing "record preview" and "record selector" settings #944
Comments
@kgodey @ghislaineguerin @mathemancer @silentninja @dmos62 @pavish I've assigned this ticket to you to review the questions above and comment with any thoughts. Please comment and/or unassign yourself. |
As far as the
The downside is that if we go that route, it would take a bit of time to change the setting. On the other hand, the upside is that it restricts the search space for possible preview column sets, which would make suggesting simpler. As for suggestions, you point out a real problem. I'm quite partial to maintaining a separate list of user-chosen and suggested preview columns. The way would be: The user chooses some (maybe zero) preview columns, and we fill in the rest with suggestions. They could turn off the suggested preview altogether (since it may be more clutter than they want), using only their chosen columns. If they do choose columns, we'd fill in the rest, attempting to make unique tuples. |
@mathemancer I assume this issue was accidentally closed. I'm reopening this. |
@seancolsen I think you make a good point in keeping preferences at the table level only. I'm wondering if record preview could be treated only as a display mode for the column, meaning it will work the same if the FK points to a different table. |
Here's the schema I would suggest: {
// this setting tracks whether to show link previews while viewing THIS table. this may not be stored here, see the end of this comment.
"show_link_previews": true,
// this setting tracks what columns from THIS table as shown as previews in OTHER tables
"preview_columns": {
"columns": [278, 279, 280],
"customized": false
}
} This namespaces the settings, allowing us to add different types of settings in the future. It also shortens setting names.
This is now
This is now
We should recompute
No, we'd be making too many assumptions to exclude any columns, I think. Dates, emails, URLs, etc. can all be unique. Also, the columns are not only used to search, they're also used to see a preview of the related record. For example, see:
In this situation, I might want to put "Watched" in the preview columns. Even though it won't help me search, it's nice to see whether I've watched a movie or not from the preview instead of having to navigate to the other table.
No, it requires too much DB knowledge to have indexes set up. We can open a separate issue to track performance issues with auto-complete if they arise. I don't think we want to automatically add indexes as part of the issue, because it'll impact write performance and we don't want to make assumptions that that's okay – the user could be using the databases in non-Mathesar applications where that will be a problem.
I was originally envisioning it as per-column. I thought it would be an addition to the Columns API ( I think this will offer the most flexibility to the user (they can expand some FKs and hide others). I'm not sure why having the setting associated with the column is problematic. @seancolsen I'll leave it to you to update the body of this ticket since you didn't specifically assign it to me. Let me know if I can help, though. |
Auto-creating indexesI said:
@mathemancer said:
But @kgodey said:
@kgodey has convinced me that we should not automatically create indexes. And I think we can focus on this topic later when we design Mathesar's indexing features. Choosing default preview columns@mathemancer said:
I'm having a bit of an intuitive knee-jerk reaction against this idea, but I'm not yet able to fully rationalize it. If others are excited to move in this direction I'll work harder on articulating my concerns. For now I'll sum it up by saying that I'm not sold on the value that this additional complexity adds. Where to store the preview toggle@ghislaineguerin said:
@kgodey said:
That seems like enough of a consensus thus far, and I agree that per-column would make the most sense from a UX perspective. However, @kgodey your proposed schema doesn't seem to store it per-column.
Then @kgodey said:
That sounds better. Are you saying What do you think about putting it in the constraints API instead? Each FK constraint would have an associated Other misc reactions@kgodey I agree with everything you said regarding:
@kgodey I'll update the ticket description once more people have weighed in and we've reached a rough consensus about all the details here. |
@seancolsen Sorry for the confusion, I was responding to each of your questions in turn and not all together. I think the actual schema should be:
|
I think it would be better to have it in the columns API since it's a display setting of a column and we already have a |
I'm onboard with @kgodey's suggestions. Regarding this comment from @mathemancer: I don't think we should override user selections. The user might actually want to only preview a single column, for eg., only select the email from the referenced table and nothing else. If we auto fill the rest, we only add more clutter. On the other hand, we should restrict the user to atleast select one column (never zero). Edit: I see that this is mentioned on the issue description and is the reasoning behind the |
Note: I revised my schema in #944 (comment) to change the setting name to |
@ghislaineguerin The user would actually be trying to search the column the mapping table refers to, so should we have provision to search through the referred column of mapping table or point them to visit the mapped table instead |
@mathemancer This is a bit confusing. You mean to suggest we find a unique row pair even though the column itself is not unique but when combined could be unique, is that right? |
@mathemancer I recommend opening a new design issue to consider this after the alpha release so we don't forget about it. It is not part of the current spec.
I like this addition to the algorithm for choosing suggested columns, I will leave it to @seancolsen to make the necessary updates to the issue.
We will not support this per the current spec, the user will have to add FKs in the mapping table directly. We can consider adding functionality for searching "through" mapping tables after the alpha release. |
Yes, exactly. |
I opened #1039 to splinter off the feature of suggesting additional columns to users during the column customization process. |
I've updated the description to reflect resolution of all the above discussion and marked this as ready for implementation now. We also had a brief discussion in Matrix about this today, making sure everyone is copacetic. |
@seancolsen I made a small update about the API paths, right under the "Specs" heading. |
@dmos62 Can you remove your assignment if you finished sharing your feedback on this issue? |
I am having issues with the spec'ed out API schema.
But having a separate route will make sense if we have user settings which would be implemented in future, so I am confused on which API schema to choose |
I had a call with @seancolsen, the options we came up with were Option 1(Spec'ed schema)Not a valid Restful API as the Option 2 (part of tables API)GET {
// ...
"preview_columns": {
"columns": [278, 279, 280],
"customized": false
}
} Option 3 (separate entity)GET [
{
"id": 1287,
"preview_columns": {
"columns": [278, 279, 280],
"customized": false
}
}
] GET {
"id": 1287,
"preview_columns": {
"columns": [278, 279, 280],
"customized": false
}
} PATCH {
"preview_columns": {
"columns": [278, 279, 280],
"customized": false
}
} We decided to go with |
Description
Motivation
Terminology
Specs
Users read/write the settings via the API. Please note that the API paths might change based on whether we've implemented multiple API namespaces (see #1029).
/api/v0/tables/<id>/settings/
(This is a new endpoint)
GET response:
PATCH request
Same schema as GET response
The
columns
property must be specified in full.All types of columns are permitted in
columns
.Record Selector performance will be best when the columns have indexes, but we are not taking any steps to enforce that at this point.
The front end can reset user-customizations by sending the following request. Then
columns
will be re-computed.Error if
columns
contains any values which are not ids of columns in the table.columns
length is not within 1 - 5.Defaults
To create a default list for
preview_columns.columns
, we use the following logic to make a best-guess of what the user would want.UNIQUE
constraints that don't also haveFOREIGN KEY
constraints.UNIQUE
constraints, fill the remaining columns with the first columns encountered that are notBOOLEAN
or have FK constraints.BOOLEAN
columns and FK-constrainted columnsWhen columns are modified
We should recompute
columns
whenever columns are added, edited, or deleted as long ascustomized
is not set totrue
. This should be part of the implementation.When a column is deleted, we remove any references to it within
preview_columns
.If the user has customized the column set and there are no columns left in
preview_columns
after deleting a column, then we set"customized": false
and re-compute the default set of columns./api/v0/tables/<id>/columns/
This endpoint already has a
display_options
property for each column. We need to modify thedisplay_options
property, adding ashow_fk_preview
property as follows:The
show_fk_preview
property will default totrue
if the user has not customized it. Later, once we have users, we may consider making this default into a user-specific setting.Questions originally posed in this ticket (now answered)
All these questions have now been answered via comments, and those answers are reflected in the ticket summary above.
The text was updated successfully, but these errors were encountered: