-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Add DB table to extend filecache with metadata etag, creation and upload time #14228
Conversation
I think it would be clever to add a few 'spare' columns. It will basically be impossible to change this table in the future once it has millions of rows. So I think this is a good idea. |
We had a few columns to add already. ctime/utime/mtime need to be covered, we only got 1or2 so far. The question with empty columns is of course, do we need more int or strings? |
Another one: what size should they have, because there are multiple sizes on the int side as well as a multitude on the string side as well. Just adding "string columns" isn't that easy because it has given implications on the performance (how easy it is to add indexes, or if this is possible at all, etc).
Good ones 👍 I would then add a creation time and an upload time column as well, right? |
Any other columns? Something like the visibility due to background scans or background processing? (I just have the antivirus app in mind for example) |
There is also a tool to migrate it on a live system: https://www.percona.com/doc/percona-toolkit/2.1/pt-online-schema-change.html (problem: it's a tool that needs manual work) |
f70dffa
to
5d9030b
Compare
I added creation and upload time as |
Anything else? |
5d9030b
to
ff73065
Compare
ff73065
to
9dc8666
Compare
Added the index names 👍 |
9dc8666
to
526137e
Compare
Ready for review 👍 |
will timestamps (mtime in filecache) and the datetimes here will be comparable? since the timestamp does not carry timezone information. i think @nickvergessen dived into this somewhat deeper some time ago? |
timestamps are by definition UTC, right? Thus it should be no problem. |
@MorrisJobke I am mistaken. DateTime does not carry time zone information, but as long as data is provided in UTC it'll be fine. |
526137e
to
ad08075
Compare
since we use timestamps (int) for storing time in the filecache I would prefer to also use that here |
This was proposed by @nickvergessen to improve handling of this in the future. I don’t have any specific preference for one or the other. What do the others prefer? |
ad08075
to
4022346
Compare
Changed. |
🤖 beep boop beep 🤖 Here are the logs for the failed build: Status of 16749: failure
Show full log
Show full log
Show full log
|
Big question now: Should we merge this? because the whole logic to properly provide the metadata etag is quite some work and the propagation that is done for the normal etag needs to be replicated to the sharing backend. That's most likely nothing we can accomplish in the remain days. I would vote for moving this to 17. Sorry for the delay here. |
4022346
to
1788595
Compare
I updated this PR and we are now fine with merging this. Once in we can focus on the actual code for the usage of those columns. |
…d upload time Signed-off-by: Morris Jobke <hey@morrisjobke.de>
1788595
to
60dcb18
Compare
Rebased. Once done I will merge this. |
woho 🎉 |
For now it’s only the table columns. No code was added yet. |
Most likely not, because the propagation code needs to be added for the metadata stuff. |
For #8477
Now the big question is: should we try to add more columns to this new table. The idea was to add some generic columns for strings, integer, bools, etc that are by default are just empty and can be used in the future then? The problem we want to solve with this is that the filecache is a big table that is not easily extendable on all possible DBs without a major downtime due to the size of the table. This is especially the case for MySQL/MariaDB where an added column results in the table being created from scratch and then is copied over and thus causing quite some downtime.
cc @rullzer @icewind1991 @karlitschek @nickvergessen @blizzz @kesselb @ChristophWurst