No idea, was never there.
An error has occurred.
1054 Unknown column 'client_id' in 'field list'
I already fixed the Database structure
Labels |
Added:
?
|
Status | New | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2017-01-20 14:15:37 |
Closed_By | ⇒ | zero-24 |
Status | Closed | ⇒ | New |
Closed_Date | 2017-01-20 14:15:37 | ⇒ | |
Closed_By | zero-24 | ⇒ |
Status | New | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2017-01-20 14:33:48 |
Closed_By | ⇒ | Bakual |
For what it is worth, there is zero technical reason why upgrades between anything but stable releases cannot be supported. The thing that usually breaks this is the way the database update deltas are managed. Part of the reason we went back to dated deltas versus one massive file for a release was to help with this (and I actually ran a couple of sites through the beta/RC period of one of our minor releases no problem). When you edit existing deltas that have been part of any tag (including alpha/beta), that's when you screw that upgrade path up.
The column "client_id" is added in alpha2 update sql
Menu manager SQL is 3.7.0-2016-11-19.sql (merged 3 days ago), while for example 3.7.0-2016-11-27.sql was already there 2 months ago. So alpha1 already contained SQL files with a higher "version" than the one from the menu manager.
That's why it's not possible to update from alpha1 to alpha2.
It should really be renamed after merge to the date it was merged because you get out-of-sequence stuff like that.
It should really be renamed after merge to the date it was merged because you get out-of-sequence stuff like that.
If we wanted to support going from alpha to alpha (or beta), we should change the date. Since we don't support it, the order doesn't matter and we can leave it as is.
Like I said above, the only thing blocking people from actually being able to update between non stable releases is the way the change deltas are managed. There is no technical reason, just the mentality of "well, we haven't hit a stable release yet, this doesn't matter". It's not like this is extra maintenance overhead.
Realize something too, you deliberately make testing the update process more difficult by stating "we only support upgrades from the last stable package to this testing package". The update process is the exact same whether I'm upgrading from the 3.6.5 tag, the 3.7.0 alpha tag, or some random commit in the middle of those (i.e. a nightly build).
see the same report here:
https://issues.joomla.org/tracker/joomla-cms/13651
Like I said above, the only thing blocking people from actually being able to update between non stable releases is the way the change deltas are managed.
It was a decision that has been made to not support it.
Of course that can be revisited and changed but currently it is the strategy and thus this issue is closed.
I think it should be revised. It just makes more sense to apply the change by merge date and help people test. I have two people message me asking how to test this new release which they were following on GIT. In the end they had to reset the branch and setup a new SQL because they are not technical enough to figure out why it's like this, yet they want to test and help which is what we are asking for.
I used nightly builds on alpha, it took a while to explore why i can't upgrade on beta1 by "custom path".
Hello all,
I have upgraded a Joomla 3.6 website to J3.7 Alpha 2 and I have the same problem (1054 Unknown column 'client_id' in 'field list'), it there any solution how to fix that?
Upgrading between test release is not supported. I suggest you do a fresh install I am afraid.
Is OK, I have the fixed this issue. Thanks
@stell
This is not supported? please install a clean alpha 2 and try again.