[Chandler-dev] Sorted subindex...not sorted properly - Rebuilding
index...installed on value...
vajda at osafoundation.org
Sun Feb 11 19:50:12 PST 2007
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
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.
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'),
> 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,
> 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
>>> 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
>>> 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
> andre_mueninghoff at fastmail.fm
More information about the chandler-dev