Hi Andi,
That much I can confirm already from my side from my testing this past
weekend, if I selected no to the timezone prompt (because sync
encountered an event with the timezone set) then the adhoc index error
would not appear. Thanks much your explanation of the possible cause. I
had been wondering if there was some relationship to when I clicked yes
on the timezone prompt. I will experiment a bit further, but my
recollection is that when I was multi-tasking during the sync and
clicked yes well after the sync completed had completed then the error
did not occur.
About bug 7324 (where 'triageStatus' indexes are going out of sort
order), I haven't seen it in the last couple of days and my hypothesis
is that I eliminated it for my repository (for now) by ensuring all
timed events were set to a timezone other than floating. I began to
chase the adhoc index error after discovering via the repository browser
(which is quite cool) that all-day events automatically have their
timezone set to floating. (I had been surprised having thought I had
removed all floating timezone attributes.) Will let you know if I am
able to make the triagestatus index error return, reproducibly.
Thanks, Andre
On Sun, 11 Feb 2007 19:50:12 -0800 (PST), "Andi Vajda"
<[EMAIL PROTECTED]> said:
>
> On Sun, 11 Feb 2007, Andre Mueninghoff wrote:
>
> > 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:
>
> Thank you, André, for the update.
>
> I suspect that the asynchronicity of the timezone dialog (the one that
> pops
> up the first time you encounter an event with a timezone) is causing
> strange
> interactions.
>
> Given that this dialog only pops up once (your answer is reused unless
> you
> uncheck that choice), could you try to answer 'No', that is, keep
> timezones
> turned off and see if you still get this error ?
>
> The error you're getting shows that an item still belongs to an index
> even
> though it doesn't belong to that index's collection. This happens when
> the
> notification about the item's changing and moving out of the collection
> is
> either not sent out or lost. In the past, we've had issues with deleting
> items (fixed during the alpha 4 release cycle). Here, I suspect that the
> answer to turn on timezones happens at a not-so-safe cycle of either item
> merging or other such delicate changes. Answering 'No' in that dialog
> (and
> keeping that answer) is a lot less disruptive to the sync process.
>
> Thanks again for your efforts.
>
> Andi..
>
> ps: That error is not the same as bug 7324 (where 'triageStatus' indexes
> are
> going out of sort order). And it is serious.
>
> >
> > Lengths of index '__adhoc__' (198) installed on value
> > 'MethodFilteredSet((UUID('4JDtF2VVx7rcKfD2ipHpY3'), 'set'),
> > (UUID('4JFSeGVVx7rcLdD2ipHpY3'), 'isFloatingEvent'),
> > ('osaf.pim.calendar.EventStamp.allDay',
> > 'osaf.pim.calendar.EventStamp.any
> > Time', 'osaf.pim.calendar.EventStamp.startTime'))' (197) of type <class
> > 'repository.item.Sets.MethodFilteredSet'> in attribute 'set' on
> > <FilteredCollection: floatingEvents
> > 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,
> > Andre
> >
> > On Thu, 8 Feb 2007 20:26:50 -0800 (PST), "Andi Vajda"
> > <[EMAIL PROTECTED]> 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
> >> the
> >> 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
> >> the
> >> server (ideally none) reproduction case and attach the corresponding
> >> repository (and chandler.log file) to a proper bugzilla bug entry, that
> >> would
> >> 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.
> >>
> >> Andi..
> >>
> >> ps: involving the server in reproducing the bugs make this extra hard as
> >> the
> >> data on the server keeps changing and may not be right anymore to
> >> help
> >> with reproducing the bug. I know, sometimes there is no other
> >> way....
> > --
> > Andre Mueninghoff
> > [EMAIL PROTECTED]
> >
> >
--
Andre Mueninghoff
[EMAIL PROTECTED]
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
