? Success

User tests: Successful: Unsuccessful:

avatar pe7er
pe7er
3 Dec 2014

with this update for existing Joomla installations using PostgreSQL

See issue: http://issues.joomla.org/tracker/joomla-cms/4875

avatar pe7er pe7er - open - 3 Dec 2014
avatar jissues-bot jissues-bot - change - 3 Dec 2014
Labels Added: ?
avatar brianteeman brianteeman - change - 3 Dec 2014
Category Postgresql Updating
avatar waader
waader - comment - 4 Dec 2014

@Bakual How can I test this with current staging?

I failed doing it the following ways:

a) Fresh install of current staging including the new update file. Result: the plugin is still protected.

b) Fresh install of current staging. Afterwards I put the update file in the respective directory. In the Extension-Manager -> Database I see this line:
"Database schema version (None) does not match CMS version (3.4.0-2014-12-03)."

avatar Bakual
Bakual - comment - 4 Dec 2014

If you click the "fix" button in the view, it should apply the SQL file and fix it. If not, it's a fail and something in the query is wrong.

avatar waader
waader - comment - 4 Dec 2014

Thanks! That´s what I though should happen. Will have to find out later that week.

avatar sovainfo
sovainfo - comment - 4 Dec 2014

Wrong answer!

Extension manager->Database is not designed to Fix this. That is why you don't see the statement in the report. It only detects there is a later change not applied.
Haven't tried the statement, but suspect there is nothing wrong with it. It happens to be an UPDATE statement, which is a DML and not DDL statement. Only certain known DDL statements are considered for Fix.

You can apply the statement with phpPgAdmin to verify the statement itself. Don't think you need to test the update mechanism, we know that works. But if you want to, you need to start with j336 and update to 337 after having renamed the file to 3.3.7-2014-xx-xx.

You need to apply the PR that changes joomla.sql before you install to check whether installation will install it as unprotected.

avatar waader
waader - comment - 5 Dec 2014

@sovainfo Thanks for your tip. I did the following:

  • take the 3.3.6 installation files
  • add pe7er´s sql update file
  • switch to the test update channel and
  • do the update
  • look for the result

It did function for mysql, but not for postgresql. This is what was display on the database tab:
Table 'efp8m_associations' does not have column 'id' with type integer. (From file 3.0.3.sql.)
Table 'efp8m_contentitem_tag_map' does not have index 'efp8m_contentitem_tag_map_idx_tag_name'. (From file 3.1.0.sql.)
Table 'efp8m_updates' does not have column 'version' with type varchar. (From file 3.2.2-2014-01-18.sql.)
Table 'efp8m_user_profiles' does not have column 'profile_value' with type TEXT. (From file 3.3.4-2014-08-03.sql.)
Table 'efp8m_redirect_links' does not have column 'header'. (From file 3.4.0-2014-09-16.sql.)
Table 'efp8m_content' does not have column 'images' with type IS NOT NULL. (From file 3.4.0-2014-12-02.sql.)
Table 'efp8m_content' does not have column 'urls' with type IS NOT NULL. (From file 3.4.0-2014-12-02.sql.)
Table 'efp8m_content' does not have column 'attribs' with type IS NOT NULL. (From file 3.4.0-2014-12-02.sql.)
Table 'efp8m_content' does not have column 'metadata' with type IS NOT NULL. (From file 3.4.0-2014-12-02.sql.)

3.4.0-2014-12-03.sql was not in that list, but wasn´t applied. So I execute the update sql in phppgadmin and that worked. Probably the update mechanism is not very robust from the moment on it encounters a problem in on sql file.
Note: fix solves the problem for all but 2 entries we now from #5186

avatar sovainfo
sovainfo - comment - 5 Dec 2014

That is not what I suggested earlier. Obviously the update failed. And as I always ask on the forum: What does logs/joomla_update.php say?

avatar waader
waader - comment - 5 Dec 2014

@sovainfo Thank you for pointing me to the log-file. I was not aware of the existence of such a file.

But as I wrote: the described procedure worked well with mysql.

The only deviation from your suggestion that I could see - maybe I have missread or missed something than please correct me - is that I renamed the file to 3.4.0-xxxx-xx-xx instead of 3.3.7.-xxxx-xx-xx. The reason for this is simple. When I turned the update channel to "testing" joomla made the update to 3.4.0-dev. And I didn´t know how to change that to 3.3.7.

I will repeat my test with progresql tomorrow and have a look into the log file.

avatar sovainfo
sovainfo - comment - 5 Dec 2014

Considering the amount of PR's related on PostgreSQL, I am not sure what would be the correct setup with 336.
The first couple of differences should not appear. They are alterations of versions before 336,

Don't like the update channel test because it is a moving target. Only suggested to update to 337 because that is a limited update, not introducing more issues than it fixes.

avatar waader
waader - comment - 5 Dec 2014

I don´t know how to update from 3.3.6 to 3.3.7 and I am curious how to do that.

avatar sovainfo
sovainfo - comment - 5 Dec 2014

Looks like it is not possible anymore.

avatar wilsonge wilsonge - close - 18 Jan 2015
avatar wilsonge wilsonge - change - 18 Jan 2015
Status Pending Closed
Closed_Date 0000-00-00 00:00:00 2015-01-18 00:43:00

Add a Comment

Login with GitHub to post a comment