[Dev] Upgrading Chandler

[John Anderson]

Phillip J. Eby wrote:

> 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.)

I either don't understand or don't agree. Trees of blocks are only 
parameters (not code, or preferences) -- ignoring the fact that a block 
belongs to a class that has methods. The fact that we make a copy of a 
template, just means we need a new set of parameters for a new 
situation, since we can't know all the situations when the repository is 
built.

It's no different from having a bunch of prebuilt Word documents 
available, so that when you begin a new document, you make a copy of one 
of the templates. Both the templates and the documents you've already 
created are data only, not code.

>
> 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.
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/dev