Good day! I am having some problem regarding my fresh upgraded openedx. To give you some background of my instance, our openedx is native installed (koa version) and through this discussion’s help from fellow developers, we’ve managed to migrate its data from native to tutor successfully, and now we are currently using the tutor deployment (olive version) in a separate instance.
We haven’t configured anything yet but our openedx seems to be having a problem. In the dropdown image below, the Profile and the Account tab doesn’t seem to be working properly.
Here is what it looks like: (I’m currently using dark mode and have the mfe plugin enabled, please don’t be confused)
I also see the following in your logs
lms_1 | account_settings = get_account_settings(: OperationalError(1054, “Unknown column ‘auth_registration.activation_timestamp’ in ‘field list’”)
I see a reference to this field in both the Profile Traceback and Account Traceback you shared.
I know you previously stated in a post that you were moving from Native Koa to Tutor. Did you migrate first to Tutor Koa and then to Tutor Lilac and then to Tutor Maple and then to Tutor Nutmeg and finally to Tutor Olive? It seems to me that you might have skipped some of the Django migrations that normally occur in-between versions.
If you did, something might have gone wrong while upgrading from one release to the other. I am sorry if I cannot tell you where this might have occured.
I would suggest you ask your DBA to look at the openedx database and check the schema for the auth_registration table because activation_timestamp should still be there at least on Nutmeg (I just checked on our production server).
I suspect something went wrong while upgrading from one release to another.
Yes. I configured it correctly. I used an online dns checker to check if it redirects to the correct DNS and it does.
Well, I do recall that through running tutor local quickstart (I’m not quite sure if I remember it correctly that it occured on the process of migrating from lilac to maple), we’ve crashed through a migration error, but we’ve managed to fix it by running migrations using migrate --fake. Does it cause any trouble from there?
I also checked our previous native koa server, and compared it to our current server, upon checking the database, even the koa version’s auth registration table has no “activation_timestamp” column.
One thing I noticed. Your database is still called “edxapp” according to your TUTOR OLIVE SERVER screenshot. It should be called “openedx” if you followed the instructions on how to import the MySQL database from Native to Tutor.
@Engr_James_Lusuegro I can confirm that the “activation_timestamp” column didn’t exist for us in Native Koa. It is definitely something that was added during the migrations from Koa to Nutmeg (and Olive).
mysql> describe auth_registration ;
+----------------+-------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+----------------+-------------+------+-----+---------+----------------+
| id | int(11) | NO | PRI | NULL | auto_increment |
| user_id | int(11) | NO | UNI | NULL | |
| activation_key | varchar(32) | NO | UNI | NULL | |
+----------------+-------------+------+-----+---------+----------------+
3 rows in set (0.00 sec)
Thank you for noticing this. But on our case, we also followed the instructions indicated here into restoring migration data which indicates that there are two methods:
a. (Recommended) Edit your MySQL dump file:
i. Add DROP DATABASE openedx; to the SQL file above the CREATE DATABASE line.
ii. Change CREATE DATABASE /*!32312 IF NOT EXISTS*/ edxapp/*!40100 DEFAULT CHARACTER SET utf8 */; to CREATE DATABASE /*!32312 IF NOT EXISTS*/ openedx /*!40100 DEFAULT CHARACTER SET utf8 */;
iii. Change USE edxapp; to USE openedx;
b. Set OPENEDX_MYSQL_DATABASE: edxapp in your $(tutor config printroot)/config.yml file. If you are using an external database provider, you should set the following
we followed b. Setting OPENEDX_MYSQL_DATABASE: edxapp in your $(tutor config printroot)/config.yml file since we’re having difficulties on of how large our database is.
Which keeps me wondering… would it affect the migration though if we followed the second option? If it does, is there a way on how can we perform the first option on a larger database?
Also, this may be it… honestly, the moment we were upgrading from koa to lilac, there seems to be an error from there… I forgot to take a screenshot of it. Our workaround was to fake it’s migrations using manage.py migrate --fake but now, I’ve realized it didn’t really fix anything.
We’re planning on starting from scratch from our migrations as you’ve indicated that there is something missing from our migrations. I hope you can still help if I would post the error here about our upgrade from koa to lilac.
Our MySQL database dump was also very large, so we used “split” in order to split the dump file in smaller chunks in order to edit the beginning of the first chunk to add the drop database instruction and replace edxapp by openedx as suggested in the recommended solution a). Of course, it also means concatenating all chunks afterwards in order to recreate the newly modified large MySQL dump file.
Thank you for your consistent replies. We will try to perform the said instructions. If problems occur, I think I would post another topic for that separate question.
One last question though, how can you perform the split and the concatenation process? If it would be quite difficult to explain, can I please just receive a reference for a starting point?
Hello @sambapete ! We’ve managed to run a new instance for tutor and attempted an upgrade. We performed the recommended migration procedure than the latter. But we’ve ran through some error. I hope you can check this one out.
Will now try this one out.