User tests: Successful: Unsuccessful:
Pull Request for Issue #26349 .
Make a new, clean installation of current 4.0-dev using an empty PostgreSQL database and note the database prefix used for this installation.
After successful installation, delete configuration.php and install again into the same database, using the same database prefix.
At the 2nd installation, previously existing tables should be backed up by renaming them.
Installation fails, error alert shown:
Apply the PR and the error no longer occurs
The constraint key was named incorrectly and there was an additional index when compared to mysql
Status | New | ⇒ | Pending |
Category | ⇒ | Postgresql SQL Installation |
Labels |
Added:
?
|
@richard67 there is administrator\components\com_admin\sql\updates\postgresql\4.0.0-2018-07-29.sql
But I have no idea how to write a postgres query to update that
I’ll check later tonight UTC+2
@brianteeman Is it ok if I later make a PR against your repo for changes on this PR? I would explain my changes there and if necessary we could discuss technical stuff also there in that other PR in order not to blow up this one here. It can also be that it will be tomorrow, because tonight I have already other tasks to do.
I would prefer that any discussion takes place here for greater visibility and archival purposes
@brianteeman That's ok, but it might take a bit time, either later tonight or tomorrow, sorry for that. I'll do my best.
@brianteeman Regarding the update SQL script 4.0.0-2018-07-29.sql
: The same error is there as in joomla.sql for PostgreSQL. Because it is a 4.0 update script and we have no Beta yet and we will not support updating from Alpha to Alpha or Alpha to Beta, only from Beta to Beta or later (Harald and George confirmed that on the German Jday when I talked with them), we can safely change that script. It would be of course much more tricky if it was a pre-4.0 script or if we were in Beta or later.
So if you make the same changes in that update sql for PostgreSQL as you did in the joomla.sql here, it will be good.
Sorry I am not changing an update sql file they should be immutable.
@brianteeman Well you could, is an exception which George recently has explained. But no problem if you feel uncomfortable with that, I can understand it because normally touching these files really causes often trouble. If you want I can make a PR later then when this is merged, I just hope I won't forget. Maybe you could ping me in addition to be safe. George then can decide what he will do with my PR. Now I have to eat, is late. Will test this PR later or tomorrow.
I have tested this item
the pr fix what is in it scope, and it was a really annoying bug for the few of us that are silly testing on postgresql, so i would go for it for now (it will save time to manually run a DROP CASCADE each time you do a re-install deleting the configuration file),
obviously there is still more to fix:
right now consistency and standards doesn't apply to postgresql unfortunately
...in the hope that this pr will be quickly merged..
after, please @richard67 , submit another pr for the needed fix to the update script and for consistency
@alikon Will test soon, am just preparing environment. Put on to-do list: 1. change index name in joomla.sql for mysql, too, to be consistent, and 2. same change in files 4.0.0-2018-07-29.sql for both db types for same reason. I've clarified that we can do that, the untypical index name which had been chosen did not have any reason like we had it in other cased.
From code review I'm sure the test will be good, but for formal reasons it needs a real test.
I have tested this item
@alikon RTC.
Status | Pending | ⇒ | Ready to Commit |
RTC
Yes that's why we have to change the update sql script. Later when this script would have been released with beta, we would have to uncomment that line in the existing script and make a new one with creating the index with new name, much complicated. Maybe I should write something on jdocs about when we could modify which scripts and in which time periods of a release cycle none can be touched.
Labels |
Added:
?
|
Status | Ready to Commit | ⇒ | Fixed in Code Base |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2019-09-23 22:48:16 |
Closed_By | ⇒ | wilsonge |
Thanks guys!
thanks
@brianteeman We should check if there is some 4.0-*.sql update script where we should make this change, too. I can check that tonight German time when back from work.