Just integrated Flyway into our app and it works great in the following situations:
brand new app install with empty schema, creates the schema_version table and executes the complete schema script after which app is on it's way..works great!
have a patch sql script, we set the version higher than the current version, patch get's applied automatically, version is incremented, no issues here!
Now the problem is the following:
We have older versions of our app out there. Say our current application version is 7.5 (schema version 1.0), when a user is using 7.4 of the application (we will manually set the schema version to say 0.9) and is upgraded to 7.5 the schema upgrade to v 1.0 should be migrated using an Upgrade script rather than the complete script for an empty database. Make sense? How can I approach this scenario, it does not seem to be covered by Flyway.
In summary we have these two scenarios:
Brand new install of our app v7.5:
- installation of new schema v1.0 uses MX_1_0__complete.sql
Upgrade of app from v7.4 to v7.5:
- upgrade of schema from v0.9 to v1.0 should use MX_1_0__74upgrade.sql
since both target schema versions are 1.0 how does Flyway choose one over the other? In addition either only an upgrade or a complete script is to be executed depending on the existing version#, not both!! If current version is 0.9 then upgrade script to be chosen, if current version is 1.0 then nothing is to be done, if there is no current version then the complete 1.0 script to be applied to create a new schema.
Should be simple enough...
Always run all scripts.
Brand new install of v7.4: Run 0.9 script.
Brand new install of v7.5: Run 0.9 script and 1.0 upgrade.
Upgrade v7.4 to v7.5 ... : Run 1.0 upgrade.
Related
I am a developer who is using python. All my code runs as a pyinstaller - made app.
Can any of you tell me how to update the app when the code is changed without having to reinstall it?
I use EMCO MSI Package Builder to pack my files into MSI package. When I need to update my application I update the MSI with new files, change its product code, version (without changing upgrade code) inside of EMCO software, and build new MSI. After that I update MSI in SCCM (or it's possible to use group policies) and wait when users get it on their PCs.
When I do symfony self-update I get the following error - how can I solve it?
Backup failed, rename D:\SERVER\Symfony\symfony.exe C:\Users\FairyWilbury\.symfo
ny\autoupdate\2019-07-19_14-57-14-79024bb-old: The system cannot move the file t
o a different disk drive.. Canceling upgrade.
UPD.
I have just realized that the latest symfony version seems to be 4.3 with 4.4 due to release in November https://symfony.com/roadmap/4.4
Yet whenever I run symfony new --full %projectName% it suggests I should update to 4.6 (and then fails to update as described above). Screenshot of the command line: What can this problem be?
First of all, you're mixing up Symfony Local Web Server and the Symfony PHP framework. You can use the web server, which is a single executable command line developer tool, to start a new Symfony-based project or start a local server that makes your web application available for testing and debugging while you develop it. The framework, on the other hand, is the code base you build web application on.
When you run
symfony self-update
from the command line, you (try to) update the web server, not the framework.
The latest version of the web server, at the time of writing, is 4.12.10, while the framework is at 5.0.5 (or 4.4.5), so, as you can see, they're completely independent from each other.
Back to the original problem, and I was struggling with this as well, the catch is that we both use Windows and installed the web server (symfony.exe) to a folder in drive D: (in your case it's D:\SERVER\Symfony). While it's running, it stores config and other files in a ".symfony" directory in the folder of your Windows user account (C:\Users\FairyWilbury). And during the self-update process, that's where it tries to move the original symfony.exe file. For some unknown reason, it cannot do that between different drives, not even in an Administrator-privileged command line window.
Strange, as it is, the only solution I found was the following.
I created a TEMP folder on drive C:
Copied symfony.exe from its folder on drive D: to C:\TEMP
Opened up command line, and switched the current dir to C:\TEMP
Ran symfony self-update -- this time it went smoothly
Closed the command line window
Moved the new symfony.exe file from C:\TEMP to the folder on drive D:
Removed C:\TEMP folder
I know it's a bit cumbersome, but we have to consider that Windows is not the most popular development platform for PHP applications. ;)
okay, look, in this case, I dont really find anything about this symfony self-update stuff, so...
In the version title the third part (so the 1 in 4.6.1) is a patch, what that only contains bug fixes, so you need the latest minor version first 4.6.0.
Basicly you need follow this doc:
symfony/doc/upgrade_patch.html
And, as it starts above, first you need follow this doc (attentively):
symfony/doc/4.2/upgrade_minor.html
This upgrade_minor.html writes: The composer.json file is configured to allow Symfony packages to be upgraded to patch versions., so ...
This command helped me to update symfony binary:
sudo symfony self-update
I have Artifactory 5.4 running and would like to upgrade it to the latest available one: 6.3.3. Do I need to upgrade it to some interim version or can I go straight to 6.3.3 ?
You should be able to upgrade from version 5 to 6 without the need for an interim version.
Before doing so, however, it is strongly suggested that you
Do a complete system export. If at any time you decide to roll back to the older version, you can use the export to reproduce the system in its entirety.
Backup your database.
Hello every time I type any dotnet command it will configure dotnet again.
I don't want to be like this, I don't want that every time I type command dotnet is configuring again. Help me turn this off.
configure again
The error message "Failed to create prime the NuGet cache. new failed with: -2147352571" hints at a known problem when you install the 2.0 CLI next to the 1.0 one and then return to run anythin in 1.0 afterwards.
Latest information on this topic is from June this year when the 2.0.0 tools were still in preview phase. The info back then was to wait until 2.0.0 is released and then there might be another update to the 1.0 series to fix problems if both are installed together.
In the meantime, you can work around this by either uninstalling the 2.0 series dotnet cli or by making sure this environment variable is set before running the 1.0 cli again:
DOTNET_SKIP_FIRST_TIME_EXPERIENCE=1
This is the original problem report with the same error message you didn't mention: https://github.com/dotnet/cli/issues/6381
Here's the discussion for the temporary fix: https://github.com/dotnet/cli/issues/6550#issuecomment-301261209
And here you find the latest information about no updates for the 1.0 series until 2.0 is final (2.0 is final in the meantime, but apparently 1.0 hasn't received any updates since): https://github.com/dotnet/cli/pull/6633#issuecomment-311882413
I have a Plone installation at version 2.5.5. I need to upgrade it to 3.3.5. I'm not terribly familiar with Plone or Zope or Python.
This is in a windows 2008 R2 environment. I have the install files for both versions and I'm not worried about breaking anything because everything is backed up a dozen times.
The steps I've taken so far:
1) backed up the old files
2) tried installing 3.3.5 to the same directory...received several DLL entry point errors at the end of the process.
3) had to restart the computer
4) after restart the version 2.5.5 plone controller was still working but the 3.3.5 controller was not.
Did I do something wrong? The notes at www.plone.org/upgrade couldn't have been more unhelpful for my experience level.
Thanks for any advice!
http://plone.org/documentation/manual/upgrade-guide/
this is a good starting point, always.
Basically install Plone 3.3.X somewhere, install the same add-ons (and check compatibility, thus), copy the data.fs over and start plone 3. If it works, run the upgrade steps going in ZMI and following the noticies.
I think no Plone upgrade over major releases I have done went without complications.
My advice is to not upgrade in-place, but instead install the newer Plone version to another directory, create a new instance and copy the Data.fs file from the old site over to the new one. So you can at least compare your new to your old site, running side-by-side.
You then use the "migrate" product to update the database. Try using "dry-run" first. If you encounter errors during migration, try to disable the products that cause the error, and re-try.
That's -- roughly -- the advice from the Plone upgrade documents.