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.
Related
I have an question regarding updates to the framework of a Laravel application.
Normally I run the composer update command to update all of its dependencies. For the laravel framework the package laravel/framework is used.
But they made some changes in this package which require you to make changes in the core application (not in composer). The core application is the package laravel/laravel.
For example, in this commit they have made a function called confirmPassword() which refers to a file ConfirmPasswordController.php in the package laravel/laravel.
But this file didn't exists on my application because my application is not up-to-date.
My question
How do i keep my core application up to date?
Errors
See a typical example of updating the dependencies but not the application here.
First of all... This is not an easy question and IMO there are MANY possible scenarios... Depending on the code you developed, the packages you're using, the version you want to use, and so on...
Anyway This is what I would do in this situation:
Let's say for example I want to upgrade from version X to version Z where Z is two major / minor releases ahead of X
Step 1
Follow the next steps for one major / minor realease at time. Once I've tried to upgrade an application from Laravel 5.4 to 5.6 and it was completely broken. So I decided to upgrade to 5.5 and test the everything was working and, in case, block at that release. Luckily when I've upgraded from 5.5 to 5.6 (after code fix) I've managed to make everything work as it should.
Step 2
Upgrade the core framework and the plugins, check for errors during the upgrade and ofc, check the official documentation for any kind of compatibility problem
Step 3
Laravel has it's own upgrade guide that should be followed step by step. A good chunk of errors can be solved simply following that guide. There may be some plugins that doesn't provide it but usually the problems are releated to new features... It's hard that a method, class or trait has completely changed from one version to another.
Step 4
This step can be omitted, but from the example you've provided maybe it's better to add it. When there is a new feature that requires a specific class or trait or whatsoever, the simplest way to check if the error is thrown because of a file missing (and that is part of the "boilerplate") or has a different nature, is to create an empty project with that specific version and make a comparison with the "default" files.
For example, if you made no changes to the LoginController, checking if the new version has any kind of updates, may be the solution.
You can do this manually, following the upgrade guide for the version you're upgrading from/to, for example this one.
Alternatively, Laravel Shift is a paid but fairly inexpensive tool that will do it for you automatically. Since it's making changes to your project, you should carefully review everything it's done.
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.
I am trying to install LXR tp parse my working folder of linux. In some of the tutorials on the web to set it up, they are trying to use the initdb-mysql script to initialize LXR's database in mysql. Well, I can not find this script in v2.0.0 but I can see it in older versions. Is that one still valid for use with v2.0.0? If not, what script I can use to setup the db for LXR v2.0.0? or if this whole DB thing was dropped how can I proceed?
on a side note: why linux projects always lack the proper documentation?!!!! I can see they have procedure for installing LXR on their own webiste and I believe it is outdated...why not update it?
Thank you!
Don't know if you're still looking for an answer, but here is one for the record.
Creating the DB is part of LXR initialization and is considered an internal step (i.e. not end-user visible). As such, it is allowed to change along the configuration process. This is why it is crucial to follow the procedure adapted to the LXR version.
LXR 2.x is configured with a configuration wizard (scripts/configure-lxr.pl) which takes care of generating the DB structure based on a template (templates/initdb/initdb-*-template.sql). These templates are not directly usable; they must be customized by the wizard to produce an initialization script custom.d/initdb.sh which you must manually launch after the wizard has finished its job.
The whole procedure for a simple case is shown on the LXR site. From the home page, select the installation link for the version you use (note that the procedure for 1.x also applies to 2.x).
For complex cases, download and read the comprehensive user's manual from SourceForge. Once again, select the manual adapted to the LXR version.
These manuals are not outdated since the LXR project has a rule to withhold release until documentation is ready.
Lets say my current production version is 1.2.3 and the new product version is 1.2.3.4.
Now, during installation, it will throw a warning message saying something like "The setup has detected the version 1.02.003 of...... already installed. This setup updates ..... to the same version that is already installed, therefore this update is not needed. Do you want to install the update anyway? "
This will be very misleading. Does anybody know a solution for this?
It is not InstallShield, but rather Windows Installer, the underlying technology has the behavior you observe. Take a look at this article, which explains how Windows Installer treats versioning.
The important part for your case is this:
Note that Windows Installer uses only the first three fields of the
product version. If you include a fourth field in your product
version, the installer ignores the fourth field.
This explains why it considers the new one to be the same version. So, the suggestion is either change the third digit, or go with small updates instead. Here is how you can apply small updates by re-installing the product.
Error in file:
/usr/local/sites/client/magento_site/app/code/core/Mage/Customer/sql/customer_setup/mysql4-upgrade-1.4.0.0.7-1.4.0.0.8.php" - SQLSTATE[42S01]: Base table or view already exists: 1050 Table 'customer_form_attribute' already exists
I tried upgrading this using this tutorial from turnkeye to go from 1.4.1 -> 1.4.2 and then to 1.6 but after all the mage upgrading was complete, when I hit the website to upgrade the database I get errors about database tables that already exist and it appears to be running a database upgrade script for a version of magento before 1.4.2. I know this error is extremely common and I have seen many blogs posts about it and read all that I have found -- I see no resolution besides starting a fresh install.
I've heard people say this can happen if a previous upgrade didn't complete successfully but I don't think that is the case here -- I think it was a fresh install at 1.4.1 (at least I don't believe I ever upgraded it). Anyone know why this is happening or how to fix it?
Note 1: I also tried the upgrade by overwriting the 1.4.1 files via SSH with successive version of magento -- always the same database errors though. If I remove the mysql-upgrade script that is failing, then another one fails in its place with a simliar 'table already exists' error.
Note 2: I also made sure I cleared /var/cache and /var/session and even tried reindexing. No success.
Looks like it is just complaining about a table already existing. Either install a fresh version of you database from before you tried to upgrade then clear cache and sessions and try again
Or
Just open the file referenced and temporarly comment out the part that is installing the table again. That should allow you to by pass the error.
Then you can download the magento Database Repair Tool to ensure that your tables are correct.