-
-
Notifications
You must be signed in to change notification settings - Fork 3.8k
feat(server): visibility column #17939
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
Conversation
03f6c3c
to
9169598
Compare
7820549
to
d0e75c3
Compare
d0e75c3
to
7c6cd82
Compare
7c6cd82
to
dcef370
Compare
8d93dbd
to
14f5b05
Compare
and "assets"."isVisible" = $1 | ||
and "assets"."visibility" = $1 |
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.
isVisible is a mechanism to handle live photos while visibility is to handle which pages an asset should be viewable from. If the effective page visibility comes from the image part, you need to be very careful when linking and unlinking them.
server/src/schema/migrations/1745902563899-AddAssetVisibilityColumn.ts
Outdated
Show resolved
Hide resolved
if (!isSync && (!asset.isVisible || asset.sidecarPath) && !asset.isExternal) { | ||
if (!isSync && (asset.visibility === AssetVisibility.HIDDEN || asset.sidecarPath) && !asset.isExternal) { |
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.
May not be an issue in practice, but there may have been cases where booleans like isVisible were not present in the object and comparisons were just operating on truthiness. If there are any cases like this in the client or server, these equality comparisons would be a change in behavior. Shouldn't happen theoretically but could be good to keep in mind.
42c3bf3
to
67ae3e7
Compare
server/src/schema/migrations/1745864846978-AddAssetVisibilityColumn.ts
Outdated
Show resolved
Hide resolved
67ae3e7
to
9f252f8
Compare
ce877c0
to
9649ec5
Compare
2aabb09
to
0be57cf
Compare
0be57cf
to
4335bac
Compare
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.
This PR is quite hard to review actually, since so many queries are affected. From what I can tell you're changing the semantics of a bunch of queries (some of them I flagged, though most likely not all), which isn't ideal and should be done in a later PR if we actually consider the current semantics "wrong".
The issue is that it's already quite hard making sure the new query still has the same meaning as the previous query. Adding extra mental overhead by also re-thinking logic shouldn't be in here IMO
e044259
to
7e83a17
Compare
@jrasm91 @danieldietzler @mertalev Queries' semantics should be preserved. The PR is ready for review again |
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.
Looks much better!
@@ -393,7 +392,7 @@ export class AssetRepository { | |||
.whereRef('stacked.stackId', '=', 'asset_stack.id') | |||
.whereRef('stacked.id', '!=', 'asset_stack.primaryAssetId') | |||
.where('stacked.deletedAt', 'is', null) | |||
.where('stacked.isArchived', '=', false) | |||
.where('stacked.visibility', '=', AssetVisibility.TIMELINE) |
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.
We used to be including hidden assets here as well, though they'd fly out in the join anyways afaict. Not 100% though.
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.
@mertalev Do you have any comments about this query?
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.
It should be fine to filter for timeline assets. It's kind of debatable whether archived or trashed assets should also be included here since getById
doesn't filter for them in the top level asset, but the PR effectively maintains the current behavior here.
52491ff
to
f1aac23
Compare
280536f
to
f0c0bc6
Compare
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.
LGTM
@@ -542,7 +548,15 @@ export class AssetRepository { | |||
.select(truncatedDate<Date>(options.size).as('timeBucket')) | |||
.$if(!!options.isTrashed, (qb) => qb.where('assets.status', '!=', AssetStatus.DELETED)) | |||
.where('assets.deletedAt', options.isTrashed ? 'is not' : 'is', null) | |||
.where('assets.isVisible', '=', true) | |||
.$if(options.visibility === undefined, (qb) => |
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.
wow, you have this same thing like 5 times, which might have to change in the future. can you make a utility method like $if(visibility !== undefined, withDefaultVisibility)
or something?
* feat: private view * pr feedback * sql generation * feat: visibility column * fix: set visibility value as the same as the still part after unlinked live photos * fix: test * pr feedback
No description provided.