I am running a module that was written by someone else. Inside the sql folder, I saw
mysql4-install-0.1.0.php
mysql4-upgrade-0.1.0-0.1.1.php
mysql4-upgrade-0.1.1-0.1.2.php
mysql4-upgrade-0.1.2-0.1.3.php
mysql4-upgrade-0.1.3-0.1.4.php
and the <version> inside config.xml is 0.1.4. Do run the correct upgrade script, do I need to make the <version> value start at 0.1.0, run the app, then move the version to 0.1.1, and run the app again .. so on. Or can I just run the app at version '0.1.4', and Magento will understand that it need to run all other previous upgrade script?
Thank you very much
You can just leave the version to 0.1.4.
Here is how it works.
When installing a module, magento looks for the install script with the biggest version that is lower or equal to the version of the module and executes it. Read this for more details.
Then it looks for all the upgrade scripts with versions between the install script determined above and the version you declared in config.xml.
So, in your case it will run all the scripts in the exact order you listed them in the question if you leave the version to 0.1.4.
The version is checked with the "core_resource" table in the database, and if the version is old then, magento searches for the necessary sql scripts to upgrade the module. To verify which version you are currently using, go to the core_resource table and check the version number for the module. Like wise if you remove the column associated with the module, then the next time any part of your magento installation is accessed, magento searches for the module, and gradually upgrades each one one by one.
Related
when deploy my Joomla Component I put in an Update File for the Database. Even if there are no changes for the Database. Is this neccessary?
AND: What are the contents? Do I have to put only these SQL-Statements for the Changes from Version 3 to Version 4 or must there be also the changes from Version 1 and Version 2?
Best Regards
DreiBaer
I've done some tests and it doesn't look like you need a SQL update file for a version of your component which doesn't need to make any database changes. However, this may not have always been the case in older Joomla version, see below.
When you install your component for on a Joomla site which doesn't already have a version of your component, the only sql file which is run is the one referenced in the install node of your manifest file. The file may be something like sql/install.mysql.utf8.sql.
So long as the site doesn't have any version of your component, then even if you are installing a later version eg, 2.3.1, and this later version does have some SQL update files, those files will not be executed, only the install file for this version (2.3.1). However in such a situation, whist the SQL update files are not executed, their version numbers are parsed and the greatest version number is stored against the component in Joomla's schemas table. If for example version 2.3.1 of your component contained the SQL update files 0.0.1.sql, 1.0.1.sql, 1.2.1.sql and 2.0.4.sql, then on first installation of this component, the schemas table will have a version_id of 2.0.4.
When updating a component the install SQL file is not executed. Joomla checks the schema version of the installed component and then executes, in order, each SQL update file which has a schema version number greater than the installed schema version number. For example if you have your component installed and it has a schema version of 1.5.2 and you're update contains the SQL update files 1.4.1, 1.5.0, 1.5.2, 1.5.19 and 1.6.0, then only SQL scripts 1.5.19 and 1.6.0 are executed and in that order.
If you install a component for the first time and it has no update file, then the schema table contains a record with a blank version_id field. If you then update that component with a version which does contain SQL update files, then the original schema version is calculated as zero and all update files are executed.
Together what this means, is that for each version of your component, the SQL install file must have all the necessary SQL statements to get the database into the correct state for your component version. On installation, even installation of a later version of your component, no updates will run, so the only SQL you can use to manipulate the database is the SQL in the install file.
So that you component can be upgraded correctly, you must have SQL update files which can take whatever the installed version is up to the version you are trying to update to. If for example an administrator has fallen behind in updating your component, and they have version 1.0.0 installed and want to update directly to your latest version, say 4.0.0, then version 4.0.0 needs to contain the updates from 1 to 2, 2 to 3, 3 to 4 and any subversions between.
There is this old article from Joomla's documentation which discusses exactly the questions you're asking, however its outdated (for version 2.5) and I think the information isn't accurate any longer.
This article says that it is necessary to have blank SQL update files for versions which don't have any SQL updates, otherwise subsequent updates with SQL update files will not be executed, however I've tested this and it doesn't seem to be a problem. This may have been true in older versions of Joomla, but is not true as of the version I tested on (3.5.7).
Its probably best practice to stick to the convention described in the documentation - including the empty SQL update files as it can't hurt, and as the behavior I found in testing is undocumented it could change without warning in the future.
The documentation also says that component version needs to match the update SQL file version, but again I found that this is no longer correct. You can use a SQL schema versioning which is totally independent from the component versioning without any problems. However, again its probably a good idea to keep schema and component version in step with each other - I can't think of a good reason why you wouldn't do this.
I want to update a module on my running WildFly10.0.0.CR4 Server with the help of a cli file on Windows.
For example I would need this to update the Infinispan plugin from version 8.0.1.Final to version 8.0.2
According to a book I am referrencing to, this could be something like
jboss-cli.bat --file=myupdate.cli
where the myupdate.cli file contains the code telling the server what to do (In this case, update Infinispan). I just need to know what to enter into that file - Best would be an example with Infinispan and a documentation on how to write such a file for other plugins by myself.
Thank you in advance!
EDIT:
It may also just delete the old version and install a completely new one, if this is easier.
You don't really want to just update random libraries/modules. Some of them, such as Infinispan, are tightly coupled to the server.
For final releases you can use patching to update an existing server. You just need to download the patch for the container you want to update.
First - does upgrading also patch?
Second - this is the main problem area, last time I tried upgrading magnento through the /downloader I lost my entire site and had to start from square one.
Most of my files are currently at the 1.9.1.1 version - and are needing to be upgraded to 1.9.2 - is there a specific order which these need to be upgraded in? What is the most efficient and effective way to get those upgrades on there.
Patching - We had our host dev try and patch our site with the SUPEE-6285 and he butchered that.. Any patches we try to do in addition to it now are useless and have no effect on our site. Is there a way to remove that patch and patch the with the newest one - being SUPEE-6482
About your first question: Yes.
About second one: always create a backup before updating and patching, and before test on a testing server never try to upgrade your shop on production server because there might be some extensions conflict.
And yes there is a specific order about patch files, if you want install all of them. because sometimes some of them are required to install a specific patch.
To revert an installed patch use this command:
sh patch-file-name.sh -R
To check installed patches history, check applied.patches.list located in app/etc/
For more information and to learn how to install and revert a patch check these links out:
http://devdocs.magento.com/guides/m1x/other/ht_install-patches.html
https://info2.magento.com/rs/magentoenterprise/images/Installing-a-Patch-for-Magento-Community-Edition.pdf
I want to know if there's any way to update from all versions (Example: 1.7.1, 1.7.2...) to version 1.8.0 using a single file (Example: mysql4-upgrade-1.7.0-1.8.0) from my own module.
there is a delimiter for that?
Thanks
It's not possible to do this in the same file.
When Magento upgrades from one version to another, it will also upgrade all versions in between provided you have the files set up.
So if someone has 1.7.0, and wants to go to 1.8.0, Magento will upgrade from 1.7.0-1.7.1, then 1.7.1-1.7.2 and then from 1.7.0-1.8.0 - providing you include all the files.
Read some more on upgrade paths here:
http://www.magentocommerce.com/knowledge-base/entry/magento-for-dev-part-6-magento-setup-resources
We have a software that has couple of executables inside. One of the executables is Windows service, and it doesn't change that often, usually we release many updates to the main executable, but the service version is same inside installer.
When service is installed first time or upgraded with newer version, we need to run custom action. We managed to solve first install part, but we don't know how to determine that version we're installing now is newer than one that already exists. Sort of if(newver > oldver) run custom action.
Thank you in advance
- Jack
You can try using the upgrade rules of your package. More details here: How to implement WiX installer upgrade?
Rob Mensching (the second answer in the linked thread) shows an example for upgrade rules. You should first familiarize yourself with the Upgrade table and how upgrade rules work. There isn't an easy answer or a quick fix for this in WiX.
Basically, you should have 2 upgrade rules
the first sets a property when an older version is found
the second sets another property when a newer version is found
After that you can use the older versions property to condition your custom action. For example, if the property is named OLDERVERSIONFOUND the custom action condition can be:
OLDERVERSIONFOUND
or something like
OLDERVERSIONFOUND > "1.0.0"
Your best bet is to store the "service" version somewhere in the registry, search for that registry value during upgrade and run your CA if newver > oldver (and the CA should also update said registry value to newver)
Note that Custom Actions are (generally) an admission of failure. I always try to separate out the configuration portion of setup to a pre-install (for sysadmins doing deployment) or post-install (for interactive installations) step - often a separate executable.
Declarative installations with no custom actions are much more reliable - if you can figure out how to rewrite the service so that your custom action is no longer required, you'll be much better off in the long term (this doesn't help when you're under pressure to release now, but it's something to think of for future releases)