Seaside 3.0.4 ... Issue 643

For Issue 643, I ran into a case during GemStone testing yesterday where there was WAUserConfiguration with a stale cache.

WAUserConfigurations _aren't_ reachable by doing the:

 WASystemConfiguration allSubclasses do: [ :each |
   each instance clearSearchContexts.
   each instance clearDescription ].

trick. I ended up doing the following to get past the problem:

 WAFileHandler default: nil

I consider this way too harsh, since it destroys any changes that a user may have made to the configuration ... I think that this really means that we have to have a fix for Issue 643 before finishing Seaside 3.0.4 ...

In the bug report, Avi, mentions that it should be possible to do a second lookup that does not rely on the cache and it sounds to me that this is the preferable solution ...

My WAConfiguration foo is not good enough to know the right answer here. I just know that Seaside users might be surprised if they upgrade their system to Seaside 3.0.4...

Dale
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

On 02/15/2011 11:14 AM, Philippe Marschall wrote:

2011/2/15 Philippe Marschall<[hidden email]>:

2011/2/15 Dale Henrichs<[hidden email]>:

On 02/15/2011 10:33 AM, Avi Shefi wrote:

Quoting my comment on issue 643:

   First of all use the following as first-aid to the build process:
   WAConfiguration allInstancesDo: [ :instance | instance
clearSearchContexts ].
   WAConfiguration allSubInstancesDo: [ :instance | instance
clearSearchContexts ].

Notice that this runs on all instances and subinstances of
WAConfiguration, therefore catching WAUserConfiguration too.

Again, this is an immediate fix to clear all cache. It is not intended
to run regularly...

Yes, I understand. I am able to get through the tests, but my concern is
that a post load doit needs to be executed to repair these things. I will
add the post load doit to the Metacello configuration, but I am reluctant to
us allInstances.

As for the fix, the options remain but nobody has replied.
I don't mind submitting a fix to this unless somebody thinks there's a
better solution... ?

I think making the cache more robust in the presence of stale entries is a
good idea ... if I understand things correctly, the stale entries can be
identified, so it makes sense to do a direct lookup if a stale cache entry
is encountered and then throw the error ...

Sounds good.

The other option would be to roll back the caching change, let it
incubate/stabilize more and do a 3.0.4 without issue 608.

I have at least another day or so of GemStone-specific work that I need to do with Seaside 3.0.4, so if Issue 608 can be stabilized in another couple of days or so, I'd say move forward with fixing Issue 643. Otherwise it might make sense to roll back...

Dale

_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev