-
-
Notifications
You must be signed in to change notification settings - Fork 3k
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
feat(server): Nullable asset dates #15669
base: main
Are you sure you want to change the base?
Conversation
f5f4059
to
52ba6fa
Compare
bc9702a
to
50de167
Compare
3a1c659
to
3723484
Compare
3723484
to
fd823d2
Compare
fd823d2
to
3b4276f
Compare
…/nullable-dates
71fc410
to
e213a74
Compare
Hello, how has this PR been tested? Is there a better way to always group those |
Any query that does an inner join on the exif table can do without those filters. The ones that don't only really need to check one of those columns since they're all set at the same time anyway (i.e. they will all be null or all non-null). |
if (!entity.localDateTime) { | ||
throw new Error('Asset localDateTime is missing'); | ||
} else if (!entity.fileCreatedAt) { | ||
throw new Error('Asset fileCreatedAt is missing'); | ||
} else if (!entity.fileModifiedAt) { | ||
throw new Error('Asset fileModifiedAt is missing'); | ||
} |
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.
mapAsset
being used in a context where this can happen is a bug. It's better to handle this with stricter typing in the input, both to catch issues before runtime and to avoid unnecessary runtime cost.
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.
I'll try to find a better solution for this, I agree it isn't very good.
withNullLocalDateTime?: boolean; | ||
withNullFileCreatedAt?: boolean; | ||
withNullFileModifiedAt?: boolean; |
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.
Why do we need this?
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 is for the searchAssetBuilder, see my code in asset.entity.ts. Maybe we need to find assets that have this as null in the future?
Otherwise, if you think it's better, I'll just add a non-null where parameter for each of the nullable dates that can't be turned off.
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 can go without this and always set the filter until there's a use-case for these toggles.
Thanks, I'll modify the code accordingly |
e213a74
to
b632b84
Compare
Currently I've done some superficial manual tests. I wanted to get some feedback from the team before diving deeper. In this PR, no asset will ever actually have a null date. All API endpoints require these dates to be set, it's only in the backend. In my subsequent PR, #14456 , the changes done here are included. In that PR we actually have null dates since the library service sets crawled assets to have null dates as placeholders until metadata extraction runs. In that case I've done more testing, doing library imports, manual uploads and so on. |
Allow fileCreatedAt, fileModifiedAt, localDateTime to be null, making them placeholders before metadata extraction runs
No dtos have changed, so clients don't need to be updated