[Chandler-dev] Sorted subindex...not sorted properly - Rebuilding
index...installed on value...
andre_mueninghoff at fastmail.fm
Sun Feb 11 18:43:57 PST 2007
Hi Andi, Hi Bryan,
Wanted to give you an update on my efforts. Although I've seen a fair
odd things, regrettably, I have had great difficulty in concocting a
reliably reproducible trigger and effect. It seems to me that, at least,
there is some issue at the intersection of floating events and having
timezones turned on. For a bit, it seemed I was near being able to
reproduce this type of error:
Lengths of index '__adhoc__' (198) installed on value
Time', 'osaf.pim.calendar.EventStamp.startTime'))' (197) of type <class
'repository.item.Sets.MethodFilteredSet'> in attribute 'set' on
4b69d8ea-b9e6-11db-cbce-9c2499ad9f03> don't match
but it stopped. For a few times, when I restored a particular one of my
personal collections from Cosmo, check and repair would show the above
error once only, and only if I turned on timezones when prompted by the
restore published shares function. I believe I was close to being to
reproduce the error with a new collection and new events essentially by
changing an all-day recurring event to a timed recurring event. It
seemed that if I had timezones turned on, and at least one other timed
event set to the timezone (Eastern) being displayed in the calendar
view, then check and repair frequently would show the above error. When
check and repair showed the above error, Cosmo was unable to display the
events for a week that contained one of these recurring events. However,
I was not able to generate the error consistently. Too much back and
forth to the server or something, I suppose. I was going to log a bug
with the personal collection where I first saw the error, checked it one
more time, and now it is checking successfully without issue so I did
not file a bug yet. I tested primarily with r13131 and r13133 on WinXP.
At one point, after trying to change an all-day recurring event to a
timed event, I observed the item revert to a single all-day event with
the end date being changed to one day prior to the start date. Odd, but
difficult to reproduce behavior.
I'll keep trying,
On Thu, 8 Feb 2007 20:26:50 -0800 (PST), "Andi Vajda"
<vajda at osafoundation.org> said:
> On Thu, 8 Feb 2007, Andre Mueninghoff wrote:
> > Repro Steps (using r13105) (not exactly mutually exclusive steps)
> > 1. create a new repository using C:\Program
> > Files\Chandler0.7alpha5>release\runchandler.bat --stderr --nocatch
> > --create
> > 2. Create new collection Untitled
> > 3. Create 2nd new collection Untitled-1
> > 4. Share both new collections to osaf.us
> > 5. Create New Event on calendar in collection Untitled
> > 6. Sync all
> > 7. Change occurence of New Event in Untitled to weekly
> > 8. Sync all
> > 9. DnD New Event to collection Untitled-1, and click on All Events
> > 10. Sync all
> > 11. Check and Repair shows the following...
> > Checking repository ...
> > Check completed successfully in 0:00:01.641000
> > <DBRepositoryView: Sharing (40)> merging 3 items...
> > <DBRepositoryView: Sharing (44)> merging 5 items...
> > <DBRepositoryView: Sharing (45)> merging 6 items...
> > <DBRepositoryView: Sharing (46)> committed 86 items (67 kbytes) in
> ... snip ...
> It would be good to try check/repair after each of the steps above.
> And stop at the first error. The errors reported in your message are not
> same as the triageStatus sort bug 7324.
> I believe I've seen these dangling ref errors too and having a simple
> reproduction case would be tremendously helpful.
> > File "C:\Program
> > Files\Chandler0.7alpha5\parcels\osaf\framework\blocks\BranchP
> > oint.py", line 123, in onSelectItemsEvent
> > self.selectedItem = None
> > File "C:\Program Files\Chandler0.7alpha5\repository\item\Item.py",
> > line 189, i
> > n setAttributeValue
> > old = _attrDict[name]
> > KeyError: <UUID: 1b5d8d38-b7eb-11db-fb56-a50e65bd82fa>
> > <DBRepositoryView: Lucene (52)> indexed 1 items in 0:00:00.094000
> The above error is also a dangling ref problem.
> If you could isolate a simple (not involving too much back and forth with
> server (ideally none) reproduction case and attach the corresponding
> repository (and chandler.log file) to a proper bugzilla bug entry, that
> be very helpful.
> > PS By the way, love the new sizable sidebar on my laptop, but it doesn't
> > render on my home PC, both Win XP Pro...go figure...will monitor.
> The XP rendering problem was fixed this afternoon.
> ps: involving the server in reproducing the bugs make this extra hard as
> data on the server keeps changing and may not be right anymore to
> with reproducing the bug. I know, sometimes there is no other
andre_mueninghoff at fastmail.fm
More information about the chandler-dev