Uh oh!
There was an error while loading. Please reload this page.
Add DB table to extend filecache with metadata etag, creation and upload time - #14228
Conversation
karlitschek
commented
Feb 15, 2019
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. |
nickvergessen
commented
Feb 15, 2019
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? |
MorrisJobke
commented
Feb 15, 2019
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? |
MorrisJobke
commented
Feb 15, 2019
Any other columns? Something like the visibility due to background scans or background processing? (I just have the antivirus app in mind for example) |
MorrisJobke
commented
Feb 18, 2019
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
5d9030bCompareMorrisJobke
commented
Feb 20, 2019
I added creation and upload time as |
MorrisJobke
commented
Feb 20, 2019
Anything else? |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
5d9030b to
ff73065CompareUh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
ff73065 to
9dc8666CompareMorrisJobke
commented
Feb 26, 2019
Added the index names 👍 |
9dc8666 to
526137eCompareMorrisJobke
commented
Feb 27, 2019
Ready for review 👍 |
blizzz
commented
Feb 27, 2019
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? |
MorrisJobke
commented
Feb 27, 2019
timestamps are by definition UTC, right? Thus it should be no problem. |
blizzz
commented
Feb 27, 2019
@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
ad08075Compareicewind1991
commented
Mar 1, 2019
since we use timestamps (int) for storing time in the filecache I would prefer to also use that here |
MorrisJobke
commented
Mar 1, 2019
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
4022346CompareMorrisJobke
commented
Mar 5, 2019
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 |
MorrisJobke
commented
Mar 6, 2019
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
1788595CompareMorrisJobke
commented
May 14, 2019
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
60dcb18CompareMorrisJobke
commented
Jul 15, 2019
Rebased. Once done I will merge this. |
tobiasKaminsky
commented
Jul 16, 2019
woho 🎉 |
MorrisJobke
commented
Jul 16, 2019
For now it’s only the table columns. No code was added yet. |
MorrisJobke
commented
Jul 16, 2019
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