Silva Issue Tracker Archive: Issue975

 This tracker has been migrated to Launchpad. Please post new messages at:
Title SilvaDocument should be installed before calling refresh_all in the 0.9.2 to 0.9.3 upgrade
Priority bug Status testing
Superseder (list) Nosy List clemens, flynt, johnny, jw, kitblake, lbenno, schluep (list)
Assigned To jw Topics Silva-0.9.3, upgrade (list)

Created on 2004-05-24.14:37:14 by flynt, last changed 2004-07-06.12:26:09 by faassen.

msg5947 (view) Author: johnny Date: 2004-06-18.14:45:26
I agree with it being more appropriate to discuss general issues on the mailing
list, and it seems that this particular problem will *not* be occurring in the
0.9.3 to 1.0 upgrade, and I just checked in a fix for the specific 0.9.2 to
0.9.3 problem with the refresh_all being called before SilvaDocument was
installed, so I will set the status of this issue to 'testing' to test the fix
and hope that resolves all of this... ;)
If there is a reason to discuss any of the other stuff mentioned in this issue,
please create a new issue with a less general title.
msg5927 (view) Author: flynt Date: 2004-06-05.22:23:11
The issue is for 092to093 upgrader. **And** for the following versions of the
upgrader. This means, also the 093to10 upgrader should be fixed in this regard,
if appropriate.

We may split a seperate issue for the general issues. HBut maybe the more
general issues are better discussed on the Silva-dev list ?
msg5922 (view) Author: johnny Date: 2004-06-03.16:11:28
I understand we want any problems fixed (whether it's today or just asap ;) but
it seems to me this is a very specific bug in a very specific upgrader for 0.9.2
to 0.9.3 which makes that refresh_all() is called before SilvaDocument is
installed. Perhaps we should split this issue in 2: one that only discusses that
particular bug and another that describes how upgrade processes can be dependent
on each other and how to provide infrastructure to fix those dependencies...
msg5920 (view) Author: flynt Date: 2004-06-03.15:06:13
Hi Johnny. This is not a stupid question. It touches an important point.
"Quickfix" is the keyword.

The concrete problem came up during Upgrade092to093. But we don't want to keep
this problem for later Upgrades.

Silva Extension Products are nor so much used yet. So every once in a while we
face some smaller problems or even architectural problems in the interplay of
Silva Extension products with Silva. The whole Vineyard project springs from
such problems and tries to solve some of them, for example. The possibility to
customize and extend Silva by use of some kind of extension products with clear
API access to Silva, "easy" working during upgrades etc is crucial for the
success of the product Silva itself. And it is delicate to deal with them from
the viewpoint of Silva, because different people find different ways to extend
and customize.

Benno already found a quickfix (so did Clemens and so did Samuel, everyone for
himself). It is important that the problems don't show up again in the 093to10
upgrade. But is is also of emminent importance, to have a clearly defined
framework, in which various Silva Extensions survive upgrades, in general in the
future. Not only via "Quickfixes".
msg5919 (view) Author: johnny Date: 2004-06-03.14:25:49
Sorry for maybe asking a stupid question, but am I right that this is a specific
issue with upgrading from 0.9.2 to 0.9.3? If so I would strongly suggest to just
switch the lines in the specific upgrade if that indeed is a quick fix. Of
course to avoid the problem in the future some thoughts must be spent on
improving the upgrader, perhaps with a check what depends on what, perhaps with
seperate upgrades per extension, but for the 1.0 it would be nice if we could
defer this one...
msg5906 (view) Author: clemens Date: 2004-06-01.10:04:16
Hm, on the other hand Samuels suggestion only to refresh the Silva
product and let extensions care for them selves is seemingly cleaner,
and at least as simple as well.
msg5905 (view) Author: clemens Date: 2004-06-01.09:51:53
A maybe stupid quick fix to it: reverse the order of the "SilvaDocument"
install and the product refresh may help (here).

Of course this is somewhat odd, as refreshing the "SilvaDocument"
together with all the other extensions seems to be odd, and it does not
solve the problem in general, but it maybe solve the problem Sam has.
msg5884 (view) Author: schluep Date: 2004-05-26.16:20:14
The problem is the upgrader sequence itself. Changing from Silva 0.9.2 to 0.9.3
requires to "upgrade content" first. This will call Silva.upgrade_093.upgrade,
which will refresh all extensions first and will install the SilvaDocument
afterwards (the "dependson='SilvaDocument'" in the of the extension
has no effect).

An new 0.9.3-compatible extension, depending on SilvaDocument, will fail trying
to reach any SilvaDocumnet features.

Oh Martijn just found my SilvaDeveloper posting
msg5883 (view) Author: faassen Date: 2004-05-26.16:12:08
Samuel has some more helpful information in trying to comprehend what's going on:

The Silva UpgraderRegistry has too much Python magic for me too comprehend its
function (leading double underscores, setdefault function)... Now I found out:
in Silva.upgrade_093, RefreshAll will first refresh all extensions and then
install SilvaDocument:

   def upgrade(self, root):
       zLOG.LOG('Silva', zLOG.INFO, 'refresh all installed products')
       zLOG.LOG('Silva', zLOG.INFO, 'install SilvaDocument')
       return root

Maybe the core Silva should not refresh all extensions automatically, but only
the core and SilvaDocument. Then it would let the Extensions refresh themselves
in their own upgrade script. 
msg5882 (view) Author: faassen Date: 2004-05-26.16:04:56
I'm not entirely sure entirely if this is the real problem, but if we just want
refreshes to happen in the right order of dependencies, then all you have to
do is make sure you depend on the right product.

Many extensions actually depend on the SilvaDocument extension (as that contains
the editor functionality and such) instead of on the Silva core. If you claim it
depends on Silva, the upgrade will happen in the wrong order.

The extension system however already sorts in order of dependency, but you do
need to put in the dependencies right.

It may be the case that we're not talking about refreshes but the upgrader
sequence itself. If this is the case I hope JW (who has done more with the
upgrade system) can give a better answer.
msg5881 (view) Author: faassen Date: 2004-05-26.16:01:34
This was posted in another issue, and explains it better:

One issue we ran into with the older upgrades:

Silva Extension products may depend on each other. Especially we had a
dependence on Silva Document. The older upgraders did not allow to specify a
specific sequence of the refreshes, and that killed us.

So, if possible, we should be able (in a public method) to set a specific
sequence for the "refresh all" method
msg5880 (view) Author: faassen Date: 2004-05-26.16:00:11
I'm not sure from all of this what the exact stumbling block is.

Is it that upgrades happen in the wrong order sometimes?
msg5879 (view) Author: faassen Date: 2004-05-26.15:56:00
I'm not sure why this got marked Silva 0.9.4, which will never happen. I marked
it Silva 0.9.3 instead.
msg5857 (view) Author: clemens Date: 2004-05-25.09:49:23
Actually the "refresh all" has been somewhat a hack I have put in 
to avoid a manual "refresh all" on all products after the upgrade.

 The reason why the "refresh all" is there in the first place if that the
view registry needs to be rebuild (as it is from SilvaViews, not 
Silva any longer). As far as I remember this is the only reason.

See the discussion in
(somewhat below the first three mailings, which discuss something completely 

 The mail from zagy quoted from there acually is here:

The original link in msg5365 is broken, maybe due to the move of tha archive to
another server (?)
msg5851 (view) Author: flynt Date: 2004-05-24.14:37:14
Silva Extension products might depend on each other. They may especially
dependent on SilvaDocument. The 092-->093 does not take care of that, which lead
to the situation that each site had to invent a hack for their own. Benno had to
find a hack and overwrite and Samuel faced the same problem and got an advice
from Clement, who obviously had also to deal with it.

Date User Action Args
2004-07-06 12:26:09faassensettopic: - Silva-1.0
2004-06-18 14:45:35johnnysetstatus: chatting -> testing
2004-06-18 14:45:27johnnysetmessages: + msg5947
title: Upgrader must care for Silva Extension Products dependencies -> SilvaDocument should be installed before calling refresh_all in the 0.9.2 to 0.9.3 upgrade
2004-06-05 22:23:12flyntsetmessages: + msg5927
2004-06-03 16:11:28johnnysetmessages: + msg5922
2004-06-03 15:06:14flyntsetmessages: + msg5920
2004-06-03 14:25:50johnnysetnosy: + johnny
messages: + msg5919
2004-06-01 10:04:23clemenssetmessages: + msg5906
2004-06-01 09:52:01clemenssetmessages: + msg5905
2004-05-26 16:20:14schluepsetmessages: + msg5884
2004-05-26 16:12:08faassensetmessages: + msg5883
2004-05-26 16:04:56faassensetmessages: + msg5882
2004-05-26 16:01:34faassensetmessages: + msg5881
2004-05-26 16:00:11faassensetassignedto: jw
messages: + msg5880
nosy: + jw
2004-05-26 15:56:00faassensettopic: + Silva-0.9.3, - Silva-0.9.4
messages: + msg5879
2004-05-25 09:49:23clemenssetstatus: unread -> chatting
messages: + msg5857
2004-05-25 09:38:34clemenssetnosy: + clemens
2004-05-24 14:37:14flyntcreate