[Dev] Upgrading Chandler

[Phillip J. Eby]

At 12:06 PM 10/12/2005 -0700, Bryan Stearns wrote:
>I've got some concerns about this proposal: the ability to upgrade seems 
>centered around being able to upgrade running Python code on-the-fly,

Code reloading is an internal development feature that has been requested 
by John and Donn.  In implementation terms, it's entirely unrelated to the 
rest of the issues.  As you may recall, I listed four different issues I 
would talk about; these could be subgrouped into "reloading issues" and 
"schema issues", with the former having to do with on-the-fly upgrades, and 
the latter being independent (and implicitly assumed to be operations 
requiring a restart).

Frankly, the idea of changing the schema with Chandler running (aside from 
adding new classes, which already works) never occurred to me as a 
requirement or even a possibility.


>  as well as to upgrade Chandler's schema without quitting Chandler. These 
> abilities appear to complicate the solution you've chosen,

Not so.  I simply commented on the fact that there are a few types of 
schema change that work *now* without quitting Chandler.  I never stated 
this as a requirement, and it never was a requirement.  I was simply 
enumerating the types of changes that can happen and their current effects 
on the system as it exists today.

No part of the schema evolution mechanism I discussed called for any sort 
of on-the-fly upgrading.  For all practical purposes, you can cut my post 
in half and consider the items relating to updating code and UI items, 
entirely separately from those involving schema and user data items.  If 
you do that, it should be clear that I'm in agreement with you: on-the-fly 
schema upgrading is not required.  I merely mentioned that adding new 
classes on-the-fly is in fact possible now, without comment on the 
usefulness or desirability of that feature.


>Instead, I'd suggest a much simpler strategy is appropriate:
>- Build a mechanism for schema upgrades that runs against a closed 
>repository; it could run as a separate tool, or at Chandler startup time 
>when Chandler detects an older repository.

The portion of my post that deals with schema evolution and user data 
upgrades actually assumes that this will be the approach, so this 
suggestion doesn't change anything in my post or reduce the essential 
complexity of the problem in any way.


>- Take advantage of John's suggestion to have the upgrade mechanism be 
>cognizant of our ability to discard and reload UI blocks completely; only 
>worry about upgrading content item schema and instances, and 
>preference/account settings.

As it happens, I didn't even get into this subject at all, so your 
suggestion also doesn't reduce any of the complexity in the issue I did 
write about.  UI evolution in the presence of user preferences is an 
entirely separate problem, caused by the conflation in CPIA between what's 
effectively "code" (or template) and what's effectively "data" (or 
parameters), placing them in the same item instead of different 
items.  (The need to have any block copying in the first place, is also a 
symptom of this confusion.)

The topic of UI upgrades does indeed fall under my theme of "upgrading", 
but my understanding was that we were going to assume that UI location 
preferences would be lost under upgrade for the time being, so I chose not 
to delve into this at the present time.