-
Notifications
You must be signed in to change notification settings - Fork 72
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 object tagging - Moodle 310 #619
base: MOODLE_310_STABLE
Are you sure you want to change the base?
Conversation
I've been pondering the idea of removing the intermediary table from the equation here. Originally the idea is we cache the tag values in an intermediary table, so the values can be easily queried on the moodle side for reporting. This allows you to have 'expensive' tags i.e. those that are computationally expensive to calculate, but also be able to query them very easily using the DB for reporting. However if we want to only have 'cheap' tags, we might be able to get away with just aggregating their values in the report data table (i.e every time report is run, it recalculates the values and sums the counts together), and then instead of querying db for the cached tags, it would simply re-calculate it the moment the object is about to get updated. The downside of this is the report generating gets a tad bit more complex and heavy because we need to constantly re-calculate the tag values (which can come from various random places in the db) as opposed to a single tag cache intermediary table. Another downside is we wouldn't then be able to track how many have actually been tagged in the external store, whereas with an intermediary table we at least know if its in there, its value is 99% of the time the same in the external store. I'm leaning towards the simpler solution which is just to have them in the intermediary table. |
bcd9fa2
to
9327509
Compare
f5928ea
to
9c7e9bd
Compare
3953b18
to
268d3df
Compare
This is mostly ready to go, will give it a test for these scenarios: Manual testing
|
b009b8c
to
b2d42f1
Compare
36e1894
to
ee3f161
Compare
ee3f161
to
4517840
Compare
4517840
to
9920ae5
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.
Hey @matthewhilton this is looking great from the code perspective. I've pointed out a few things I've noticed, but these are mostly just some extra considerations and discussion points. I've focused more on reviewing the code and haven't tested this end to end myself - so I'm partly relying on your test results for that.
My only real concern here is the perform at scale, mostly when back filling with the adhoc task, but this is an optional feature so I think it should be fine to roll out and test as needed.
I've not addressed all the comments yet, but just an fyi pushed an update to add a bit more visibility to the migration progress, now there is a nice table in the admin settings (for a lack of a better place to put it), let me know if you see any tweaks that should be made here, or if there are better styling options available (I couldn't find any): Additionally pushed a CI fix, since moodle plugin ci looks to have updated on my local and was throwing errors where it wasn't before. Note the Github CI is failing due to an upstream nvm issue which i've been tracking but is not fixed yet (so it will stay red for now) |
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.
Thanks @matthewhilton - feels like you went above and beyond with the changes so far. I've left a couple of new comments on these.
d50151c
to
d0f301b
Compare
Just marking as draft temporarily, will be adding some features we discussed internally and then will re-open it. |
7d37b44
to
16cc4b1
Compare
a035f35
to
93c2d88
Compare
Summary
Allows objectfs to send tags for an object to external stores. Initially only S3 is supported.
location
andenvironment
tags are added.For technical reasons,
mimetype
is also stored but this is stored in metadata instead of the tags (and thus is only for new objects, migration of metadata is not feasible)The use case for this is to be able to setup conditional lifecycle rules to send orphaned files to deep archive and eventually delete them.
See #11 (comment) for the rationale behind using S3 tags instead of other methods such as file prefixes or separate buckets.
How it works
See TAGGING.md
Cherry picks
MOODLE_402_STABLE
-> Add object tagging - Moodle 42 #623Related issues