|
Previous
·
Next
|
daFool
|
Date: 1/10/2008 5:36 am · Subject: Broken update 7.4.20 · Rating: 4
Update to 7.4.20 drops column 'dateSubmittedBy' from table Post which is still in use in the code: 2008/01/10 13:09:16 - FATAL - doku2010.conf - main::[[undef]] - Couldn't execute
prepared statement:
select
asset.assetId,
asset.className,
assetData.revisionDate as revisionDate
from Thread
left join asset on Thread.assetId=asset.assetId
left join Post on Post.assetId=Thread.assetId and Thread
.revisionDate = Post.revisionDate
left join assetData on assetData.assetId=Thread.assetId
and Thread.revisionDate = assetData.revisionDate
where
asset.parentId='maUGtU0kZVWrHQxHXiqmyA'
and asset.state='published'
and asset.className='WebGUI::Asset::Post::Thread'
and assetData.revisionDate=(
select
max(revisionDate)
from
assetData
where
assetData.assetId=asset.assetId
and (status='approved' or status='archiv
ed')
)
and status='approved'
group by
assetData.assetId
order by
Thread.isSticky desc,
dateSubmitted
desc : With place holders: . Root cause: Unknown column
'dateSubmitted' in 'order clause'
|
| Back to Top |
Rate [ | ]
|
| |
Graham
|
Date: 1/10/2008 9:40 am · Subject: Re: Broken update 7.4.20 · Rating: 0
None of the core code refers to that field anymore. You may be using a custom asset that is causing your problem. Those fields were removed in 7.4.10. An SQL Report could also refer to the field and cause problems. It now uses asset.creationDate and revisionDate. Closing as not a bug.
|
| Back to Top |
Rate [ | ]
|
| |
jigou
|
Date: 1/10/2008 10:10 am · Subject: Re: Broken update 7.4.20 · Rating: 3
Graham, this sounds a lot like the posts that both Susan and I have made in the support forum after upgrading. I know our site was not using any custom assets, but on several of the collaboration systems I had to edit and save the CS in order to get rid of this error....and that's all it took to fix it. I upgraded from 7.3.18 to 7.4.19, only pausing at 7.3.22 as needed, so I'm not sure exactly where the problem might have started....but it's very possible there's something not getting comlpetely cleaned up after the removal of that field in 7.4.10. Jarrod
|
| Back to Top |
Rate [ | ]
|
| |
susanb
|
Date: 1/10/2008 11:45 am · Subject: Re: Broken update 7.4.20 · Rating: 1
I know that my problems with the lost fields were with a
recentDiscussions macro we created as per JT's guidance a few years
ago in this forum. I haven't noticed any problems in core, at least
not yet. :-)
--Susan
|
| Back to Top |
Rate [ | ]
|
| |
JT
|
Date: 1/13/2008 10:53 pm · Subject: Re: Broken update 7.4.20 · Rating: 2
This is most likely due to not restarting apache after the upgrade.
|
| Back to Top |
Rate [ | ]
|
| |
daFool
|
Date: 1/21/2008 1:49 am · Subject: Re: Broken update 7.4.20 · Rating: -1
This is most likely due to not restarting apache after the upgrade. I did that. I do not know what finally resolved the issue. First I tried to upgrade from the last 7.3 stable directly to 7.4.20 and then to 7.4.19 without success. Then I upgraded gradually (7.4.8 was the version that dropped the columns) to see which version would break the installation. And none did.
|
| Back to Top |
Rate [ | ]
|
| |
Graham
|
Date: 1/29/2008 11:01 am · Subject: Re: Broken update 7.4.20 · Rating: 1
I checked the upgrades, and as far as I can tell all cases have been taken care of. I also wasn't able to reproduce this. Closing for now. Reopen if you can provide more details to reproduce.
|
| Back to Top |
Rate [ | ]
|
| |
