-
-
Notifications
You must be signed in to change notification settings - Fork 7.6k
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
Rename audit logs table name #15719
Rename audit logs table name #15719
Conversation
Would it make sense to create an internal migration for that to minimize the friction? |
Codecov ReportBase: 47.60% // Head: 67.21% // Increases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## main #15719 +/- ##
===========================================
+ Coverage 47.60% 67.21% +19.61%
===========================================
Files 448 1098 +650
Lines 15785 23289 +7504
Branches 3388 4110 +722
===========================================
+ Hits 7514 15654 +8140
+ Misses 6864 6753 -111
+ Partials 1407 882 -525
Flags with carried forward coverage won't be shown. Click here to find out more. Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
@gustav I considered it but since the feature has only been available for EE gold users for 2 weeks, I don't think it impacts many users/events, so I'm not sure it's worth the development and the coded added to the codebase. But to be honest I'm not sure how that works either, maybe it's actually easier than the migration guide. Do you maybe know a place where we've done since before so I can have a reference? Also one of my concerns is that this issue was brought up by users who built their own audit log feature before, using the same table name. If we do an automated migration, I'm afraid we might rename their database table, which would create issues as they don't have the same schema, and they don't want to lose their previous data |
I think technically changing the name of the table would qualify as a breaking change - even if mentioned in the migration guide - and we should make that transition as easy as possible. @petersg83 might be able to help you how to setup a migration. Imo it is very easy and renaming the table is not very expensive. I see your point about the tables they have created themselves. I think this could be mitigated by also checking whether the table matches a certain structure to make sure it is not one we have created by our audit logs implementation - maybe there are better ways. In any way I think it would be nice if you could try and explore that together if possible :) |
if (shouldMigrate) { | ||
// Migrate the name audit logs table | ||
if (await strapi.db.getSchemaConnection().hasTable('audit_logs')) { | ||
await strapi.db.getSchemaConnection().renameTable('audit_logs', 'strapi_audit_logs'); |
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 wanted to store the schema connection in a variable, but it would throw errors, it looks like I have to get a fresh one every time
@gu-stav Pierre did help me, so I updated the PR with an auto-migration 🙂 |
@remidej Cool thanks. I'll remove myself from the reviewers and add @petersg83 and @Marc-Roig instead :) |
|
||
if (shouldMigrate) { | ||
// Migrate the main audit logs table | ||
if (await strapi.db.getSchemaConnection().hasTable('audit_logs')) { |
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 should validate a bit more than the name to make sure we aren't renaming someone's custom implementation. Best to verify the model vs table structure.
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 Derrick, yes that's a definitely a concern we need to have, but do you think that can still occur here? The hasTable
here is just an extra check, but when defining shouldMigrate
we're checking if the content type admin::audit-logs
has had its collection name updated from audit_logs
to strapi_audit_logs
. With the admin::
prefix I don't think it would impact any user's content type
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.
Unless they used patch package to inject the content-type. Better safe than sorry to ensure the attributes of the collection type match exactly to the DB tables. This is something @gu-stav mentioned in his comment above too.
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.
Got it, I added another check
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.
- then, to simulate the upgrade to 4.6.1, change the collection name again to strapi_audit_logs and restart the app
- go to the audit logs, make sure you see your previous action, AND that it has the user attached to it
After these steps I lose my previous actions / user
@markkaylor that's weird, could you add some comments to check if the migration code is ever reached? |
Sure I'll dig a bit, but I think it does reach since I do see the table name changed in the db |
@markkaylor the db will have the strapi_audit_logs table even without the migration, the migration just makes sure it's created by renaming the previous table, instead of from scratch with no content |
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.
@remidej, I forgot to pull latest changes 🤦♂️, classic. LGTM!
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.
Tested again, looks good.
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 :)
Changes applied & approved by @petersg83
What does it do?
audit_logs
tostrapi_audit_logs
admin::audit-logs
content type changes the collection name fromaudit_logs
tostrapi_audit_logs
Why is it needed?
strapi_
prefixHow to test it?
1st check that audit logs work as usual: make actions in the admin, make sure you see them in audit logs.
Then test the migration:
audit_logs
, as it was before, and restart the server. All previous audit logs will be deleted, but this is expected.strapi_audit_logs
and restart the app