Migrate records from tabGL Entry to tabPayment Ledger Entry.
Patch is non-resumable. if patch failed or is terminatted abnormally, clear ‘tabPayment Ledger Entry’ table manually before re-running. Re-running is safe only during V13->V14 update.
Note: Post successful migration to V14, re-running is NOT-SAFE and SHOULD NOT be attempted.
After restoring a backup of a V13 system to a new V14 system I saw the above remark in the logs.
Does this mean that, in future, bench migrate will break my installation if anyone ever runs it?
bench migrate checks for a Patch Log entry for each of the patches mentioned in patches.txt. If an entry is found for a patch, it will be skipped. Once migration is successful, a Patch Log entry will be created for each patch that ran successfully.
So, a normal bench migrate in a V14 instance won’t break the system.
In your case, you’ve mentioned you’ve restored a V13 backup on a V14 instance(this is not advisable). Which means, the restore operation would have removed the Patch Log for migrate_gl_to_payment_ledger and bench migrate will run that patch if you do bench migrate.
Since the restore operation also clears the tables by default, patch will run successfully as the Payment Ledger Entry table will be empty. Subsequent bench migrate will not run this patch again.
But, this is not a guarantee, i’m just guessing based on the description of your scenario.
V14 was a major refactor, like splitting of modules into separate apps and introduction of many new doctypes. Restoring a V13 data backup on a V14 instance is not advisable. The Correct approach would be to restore on a V13 instance and then do a migration to V14.
I am trying to do as you say but I am unable to find instructions for migrating a V13 installation to V14. All the posts I have found here say that restoring a V13 data backup to a V14 instance is the least problematic way to do it.
Would you point out the correct instructions to me please?
I have done this multiple times without issues. The only possible problem here is with custom apps and customisations but as far as database migration is concerned this is indeed the least problematic. I have also moved from 13 to 14 using the migration process and every attempt has its unique challenges.
But i’ll suggest building a test instance and attempting the backup-restore process on it to identify any unique issue you might face so you can learn what they are and how to tackle them before attempting migration of your production server.
I have actually developed an environment variables driven script that automates the entire process.
With a single command I can start from a fresh Ubuntu 22.04 LTS VPS and create a fully operational V14 clone of a V13 or V14 production site with a completely different URL on a different hosting service, with UFW, Fail2Ban, LetsEncrypt, Google Sign In, etc as well as all my customizations, all correctly configured.
As you can imagine I have been reverting my VPS servers to snapshots hundreds of times.
I had been restoring the origin V13 site into the V14 installation, but I have now re-coded it to upgrade to V14 after restoring the database.
I am grateful for your input, of course. It is always clear, correct, relevant and much appreciated.
As it stands right now, the set up seems easy, but a small error in the environment variables leaves me with hours of debugging to figure out what the mistake was, and more hours figuring out what to do about it.
If you have some abilities with bash scripting I would be delighted to have your help with testing, documenting and making it easier to use.
Thanks for your private message. Sorry if it is weird but I’d rather answer publicly to forestall similar ideas.
I must not have been expressing myself well.
I have been refactoring and adding to these scripts for a long time. They are large and comprehensive, with many bash tricks that took a long time to get right. However, I really can run the scripts, go away for an hour, come back and immediately log into a complete V14 clone of a V13 site. I change parameters and run again to get a slave site on a different continent with a different hosting service. Run a different script and have continuous backup from the master clone to slave clone.
The problem is that that add’n-tweak development process has meant that the code has ended up very messy. It really needs a rewrite using Ansible and Python, but the cost:benefit to me is far too high to be worth undertaking.
I ask about bash skills only in the context of an ability to prepare to use the scripts at all. The only way forward, if problems arose, would be for me to review the setup myself (SSH access to a disposable test VPS you would provide)
I am very reluctant!
I have already gone to great lengths here to publish a script suite suitable for public consumption. A lot, like … really a fuqton of work! Before starting on it, I asked if anyone would be interested and got many very positive responses. I believed what I heard and invested the time to make it as solid as possible for beta-testing.
End result? Nothing. Zero. Not one of those people has ever even looked at it.
To be fair I was one of those who volunteered to test the script and I really did set up my environment and started testing… then I encountered a few snags. As I was really busy with a project at the time I suspended my effort and hoped to return to it at a later date… that was a few months ago and events took my attention away from it completely. I will dust off my passkey to the moribund instances and restart the tests this weekend. Hopefully I will have good feedback for you by the end of my tests.
I think you’re probably right…people are using it but saying nothing. We get busy doing one thing, and then another comes up and it takes a while to get back to the original project…by which time we forget to comment or say thank you.
So…sorry, and thank you for your work! It IS appreciated, even when not acknlowledged
