Set filter when following a foreign key #232

Closed
remys opened this Issue Jun 16, 2016 · 4 comments

Comments

Projects
None yet
2 participants
@remys

remys commented Jun 16, 2016

When clicking the icon to open the "foreign key pop-up window", the pop-up's filter should be initialized with the referenced value

@jakob

This comment has been minimized.

Show comment
Hide comment
@jakob

jakob Jun 17, 2016

Owner

Does this make sense? Then only a single row would be shown. Right now, the popup has the same filter it had last time it was used, and the referenced value is selected.

However, it might be a good idea not to store the filter; most times you probably want to search for different rows each time...

Owner

jakob commented Jun 17, 2016

Does this make sense? Then only a single row would be shown. Right now, the popup has the same filter it had last time it was used, and the referenced value is selected.

However, it might be a good idea not to store the filter; most times you probably want to search for different rows each time...

@remys

This comment has been minimized.

Show comment
Hide comment
@remys

remys Jun 17, 2016

The use case is to “drill down” to the referenced table;
Example: I have one table “document” containing several attribues describing a document and one table document_attachment containing a bytea attribute with the scanned document.
When browsing document, I would then like to “drill down” to the attachment by opening the “foreign key pop-up”, positioned on the specific row.
In the case of a bytea field, this is particularly important because downloading all the rows of “document_attachment” is quite inefficient. (Actually that’s why I have split my table in two parts (actually a 1:1 relation)
As an alternative, may be there could be a way to do a “lazy download of bytea attributes”, e.g. to download it only when shown in the detail pane of the browser.

On 17 Jun 2016, at 09:21, Jakob Egger notifications@github.com wrote:

Does this make sense? Then only a single row would be shown. Right now, the popup has the same filter it had last time it was used, and the referenced value is selected.

However, it might be a good idea not to store the filter; most times you probably want to search for different rows each time...


You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub #232 (comment), or mute the thread https://github.com/notifications/unsubscribe/AAJg-K3ykXla5Uc_2DkdLvngu2r-k9b9ks5qMksSgaJpZM4I3nb1.

remys commented Jun 17, 2016

The use case is to “drill down” to the referenced table;
Example: I have one table “document” containing several attribues describing a document and one table document_attachment containing a bytea attribute with the scanned document.
When browsing document, I would then like to “drill down” to the attachment by opening the “foreign key pop-up”, positioned on the specific row.
In the case of a bytea field, this is particularly important because downloading all the rows of “document_attachment” is quite inefficient. (Actually that’s why I have split my table in two parts (actually a 1:1 relation)
As an alternative, may be there could be a way to do a “lazy download of bytea attributes”, e.g. to download it only when shown in the detail pane of the browser.

On 17 Jun 2016, at 09:21, Jakob Egger notifications@github.com wrote:

Does this make sense? Then only a single row would be shown. Right now, the popup has the same filter it had last time it was used, and the referenced value is selected.

However, it might be a good idea not to store the filter; most times you probably want to search for different rows each time...


You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub #232 (comment), or mute the thread https://github.com/notifications/unsubscribe/AAJg-K3ykXla5Uc_2DkdLvngu2r-k9b9ks5qMksSgaJpZM4I3nb1.

@jakob

This comment has been minimized.

Show comment
Hide comment
@jakob

jakob Jun 17, 2016

Owner

Lazy loading of large fields (bytea, geometry) would be a good idea; see also #212. I'm not sure how much effort that would be to implement...

Owner

jakob commented Jun 17, 2016

Lazy loading of large fields (bytea, geometry) would be a good idea; see also #212. I'm not sure how much effort that would be to implement...

@jakob

This comment has been minimized.

Show comment
Hide comment
@jakob

jakob Aug 5, 2016

Owner

In Postico 1.0.9, I've added a heuristic that resets the filter. I don't want to add a filter that only shows the selected row, because that would be very inconvenient for data entry.

I'm closing this issue, since the real solution for the problem with loading times is lazy loading, which is tracked in another issue.

Owner

jakob commented Aug 5, 2016

In Postico 1.0.9, I've added a heuristic that resets the filter. I don't want to add a filter that only shows the selected row, because that would be very inconvenient for data entry.

I'm closing this issue, since the real solution for the problem with loading times is lazy loading, which is tracked in another issue.

@jakob jakob closed this Aug 5, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment