Context: Any Anvil app that has multiple databases. Specifically, each database has its own Users table.
Copying a user from one database to another means replicating their Users row entry, plus any rows they may own, in other tables.
You might do this, for example, if you need to do a major database restructuring. Keep the “before” database as-is, for a quick roll-back, in case the “after” database (or its code) doesn’t work out.
In the “after” database, you’d need to re-create all the Users. Clearly, these new database rows will have their own row ids. I’m not really concerned about that. I can “tag” each of the source rows, giving each one a persistent, cross-database id, ensuring that I can match them up later.
My real concern (for this post) is the password column, or rather, planning for it. If I copy the password column values to the new Users table, should I expect the (copied) passwords to work?
If not, then I should avoid copying the Users table, and should instead share it between the “before” and “after” databases.
Unless the hashed passwords are salted in a way that depends from the table, it should work.
You can share the user table across apps, so the hashed value does not change with the app. It could change with the table, but the only way to know is to try… or to ask the Anvil team, but trying I think is faster. You can quickly duplicate the users table, make a test app and use that duplicate in the users service of the test app.
Another thing to keep in mind is if you have enough down time to test the between before and after. You may not want to allow users to register on the old while you have started the switch or to register on the new and then you need to switch back.
I figured that if anybody has already tried it, they might answer here. Otherwise, I’ll try it myself, and post the result.
Excellent point! I have crude mechanisms for bringing the app “down for maintenance”, to prevent (unauthorized) database changes during the maintenance/transition time.