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