Export/Import `core_admin_auth` configuration referencing `admin_roles` by `code` field instead of record `id`.
psunderhaus-alto opened this issue · comments
Export/Import core_admin_auth
configuration referencing admin_roles
by code
field instead of record id
.
Summary
I'll start by saying, I'm not sure that this is really in config-sync's control, but I've observed that when the core_admin_auth
configuration is exported from the database, the values exported for the defaultRole
and ssoLockedRoles
fields reference the id
field of the admin_roles
table. I am wondering it is at all possible to reference the code
field on this table instead of the id
.
I am in a situation where my environments are a little out of sync in the admin_roles
table. I've observed that the code
field is identical whereas the id
is not.
I understand it may not be possible to refer to the code
field as this is Strapi's configuration and this plugin is simply making it portable. Do you have other advice? I'm still in development, so it is an option to hit the ol' reset button on these environments to clean things up, presumably alleviating my need for this. I'd have to put some other guard in place to ensure this table not fall out of sync again though.
If, in your opinion, it's much more reasonable to suggest Strapi be changed to use the code
values in the core_admin_auth
config, I think this plugin would "just work". I'm happy to take this to Strapi directly.
Why is it needed?
Record ids in the core_admin_auth
config aren't exactly guaranteed to match up across environments. An alternative reference may help my case.
Suggested solution(s)
When exporting this configuration item, lookup the code
field for the admin_roles referenced by id
in the defaultRole
and ssoLockedRoles
fields. Export the code
. On import, lookup the record id
by the code
and write the id
to the database entry.
Related issue(s)/PR(s)
A cursory look at the repository history didn't turn anything up.
Thanks for reporting this issue.
You bring a valid point to the table.
The plugin steers away from using id
's for identification as much as possible.
That auto-increment id
just doesn't work nice across different databases (as you mentioned).
And for the most part, the plugin can avoid them fairly well. Even relational field values can be ID'ed without using the actual id
.
Though for the specific config you're describing (core_admin_auth
) it's more like a value dump. Not relational and no corresponding schema. This pretty much goes for the entire core_store
config type btw. It's just random JSON storage.
That being said, in theory this can be fixed. But in reality, that would be an endless battle.
Each new "magic" config value in the core_store table needs to get it's own exception.
Also, with Strapi v5 the uuid
s will replace the traditional auto-increment id
.
By then this issue will have resolved itself as those will be constant throughout databases.
Vote +1 for an earlier fix.
Also, with Strapi v5 the uuids will replace the traditional auto-increment id. By then this issue will have resolved itself as those will be constant throughout databases.
Interesting, Boaz, thanks for the background. What about the use of uuid
s across databases guarantees consistency when spanning databases? Is Strapi v5 using criteria other than record timestamps to produce the same id values?
What about the use of uuids across databases guarantees consistency when spanning databases? Is Strapi v5 using criteria other than record timestamps to produce the same id values?
Yes. You can read about it's detailed design here: https://github.com/strapi/rfcs/blob/v5/database/rfcs/xxxx-v5-database.md#document-id-and-entry-id