I have added code to cache Db for my Yii2 application, it works perfectly as expected, but the problem I am facing due to that is, everytime I add any new column to the Db, application complains about the missing column due to caching mechanism. So I have to every time either add Yii::$app->cache->flush(); into my migration file manually or clear it from server, which is kind of annoying and I might miss that. Is there any way to automate this, like add this line at end of every new migration created automatically?
Related
I am using Django as my web framework with Django REST API. Time and time again, when I try to migrate the table on production, I get a litany of errors. I believe my migrations on development are out of sync with production, and as a result, chaos. Thus each time I attempt major migrations on production I end up needing to use the nuclear option - delete all migrations, and if that fails, nuke the database. (Are migrations even supposed to be committed?)
This time however, I have too much data to lose. I would like to preserve the data. I would like to construct a new database with the new schema, and then manually transfer the old database to the new one. I am not exactly sure how to go about this. Does anyone have any suggestions? Additionally, how can I prevent this from occurring in the future?
From what you're saying, it sounds like you have migration files that are out of wack and you're constantly running into issues relating to database migrations. I would recommend you just remove all of your migration files and start with a new initial migration after you make all the necessary model changes and restructuring of the schema.
When it comes time to make the migration on your production server, it might make the most sense to --fake-initial and manually making the database changes outside of Django so it matches your schema.
I might get a lot of backlash about this and obviously use your best judgement, but from my experience it was much easier to go about this problem this way and not wasting time making custom migration files that try to fix all of your problems.
Addressing your other questions
Time and time again, when I try to migrate the table on production, I get a litany of errors.
I highly recommend you take the time to get acquainted with how to make migrations by reading the official Django docs, you will save yourself a LOT of headache.
... each time I attempt major migrations on production I end up needing to use the nuclear option - delete all migrations
You shouldn't be deleting your migration files every time there's an issue.
Are migrations even supposed to be committed?
You should definitely be committing your migrations. If you're working on a team, they would be using the migration files you created to make the necessary changes on their local DB as well as any dev/prod server you may have.
So I have created a project in Vb.net, and have been retrieving, inserting, and updating data from an access database using it. I have realised that I must change some of the records within the database and went about doing so in access (having opened the database within the debug folder). So I would update the records, and then save, before closing it. Whenever I reopened it again, it had reverted to the older version. When trying to overwrite, it corrupted some of the records and sometimes the whole database, saying "Id" is not valid. Is there an error in my logic? Do I have to make a new database connection?
You're making changes to the wrong database. The original is, or at least it should be, in the project folder. When you build, that original is copied to the output folder. That way, any changes you make while debugging do not pollute the original, so it's clean when it comes time for you to release your application.
i was working on an application and drop/creating the database on each launch. Now, before going into production, i enabled migrations. I created an initial migration, then changed one of my models, added a new migration, updated the database, and everything was dandy
now, I tried to change the database name in the context, to see how it would behave on a new database, and every time I launch the application I get a differed exception.
right now its "invalid object name".. on one of my tables i think. I'm looking at answers here and they say to refresh the intellisense cache but I can't find where. I went to edit -> intellisense -> theres no refresh cache, theres refresh remote resources, which didn't fix anything.
by the way, do I have to turn automatic migrations on? (i.e. 'true')
I am trying to get this IndexedDB stuff working in a Metro (Windows 8) app, using JS.
I thought I was good, but then I ran the WACK tool a couple of times, just to see if I ran into any issues.
After these tests the IndexedDB.open call no longer opens my database (which has 7 entries in it) instead it fires onupgradeneeded, and gives me a blank (new) database (since I create an object store in the onupgradeneeded handler).
I did not change my version number, I did not change the database name. So I am guessing the applications domain somehow changed during the WACK tests.
Does anyone now how to get my database domain back?
One of the things the WACK test probably does is doing a fresh install of the app checking if everything goes fine. So when the app is installed for the first time you have to provide a creation of the database, this is done in the onupgradeneeded event.
I think you forgot to provide this, and that is why he creates a new blank database. Instead of a new database with the required structure.
I have just done a quick search and nothing too relevant came up so here goes.
I have released the first version of an app. I have made a few changes to the SQLite db since then, in the next release I will need to update the DB structure but retain the user's data.
What's the best approach for this? I'm currently thinking that on app update I will never replace the user's (documents folder, not in bundle) database file but rather alter its structure using SQL queries.
This would involve tracking changes made to the database since the previous release. Script all these changes into SQL queries and run these to bring the DB to the latest revision. I will also need to keep a field in the database to track the version number (keep in line with app version for simplicity).
Unless there are specific hooks, delegate methods that are fired at first run after an update I will put calls for this logic into the very beginning of the appDelegate, before anything else is run.
While doing this I will display "Updating app" or something to the user.
Next thing, what happens if there is an error somewhere along the line and the update fails. The DB will be out of date and the app won't function properly as it expects a newer version?
Should I take it upon myself to just delete the user's DB file and replace it with the new version from the app bundle. OR, should I just test, test, test until everything is solid on my side and if an error occurs on the user's side it's something else, in which case I can't do anything about it only discard the data.
Any ideas on this would be greatly appreciated. :)
Thanks!
First of all, the approach you are considering is the correct one. This is known as database migration. Whenever you modify the database on your end, you should collect the appropriate ALTER TABLE... etc. methods into a migration script.
Then the next release of your app should run this code once (as you described) to migrate all the user's data.
As for handling errors, that's a tough one. I would be very weary of discarding the user's data. Better would be to display an error message and perhaps let the user contact you with a bug report. Then you can release an update to your app which hopefully can do the migration with no problems. But ideally you test the process well enough that there shouldn't be any problems like this. Of course it all depends on the complexity of the migration process.