@untitaker well she replied: https://plus.google.com/u/0/105051985738280261832/posts/hWssyz2ARTY?cfem=1
NOTAPROBLEM HAHA
TransactionTooLargeException when "Removing non-dirty resources that are not present remotely anymore"
@untitaker well she replied: https://plus.google.com/u/0/105051985738280261832/posts/hWssyz2ARTY?cfem=1
NOTAPROBLEM HAHA
NOTAPROBLEM HAHA
That is not what she replied, and while I can’t judge whether her answer is reasonable, it definetly seems that way to me. Also you posted your request in an entirely unrelated conversation.
@untitaker please link the related conversation then.
And she replied that its not a bug. So you can close your issue now.
please link the related conversation then
I have no idea what you mean by that.
@untitaker And I have no idea why you think this conversation is unrelated.
The post of Dianne that you replied to was: “As usual, great talk for developers on what is new in the next release!”
If you think that is unrelated post, then please link related discussion.
Hint: there isn’t any because Google closes Issues as Obsolete.
@untitaker Dianne replied — not a bug, it is you who does something wrong. I think you can close your issue now.
Not sure, if this gets picked up, but as described in another thread, I have the same problem.
https://forums.bitfire.at/topic/743/calendar-crashes-syncing-with-transactiontoolargeexception
I checked how many calendar entries I have and it is ~5500 distributed over 5 calendars. That does not sound too much in my ears. So what to do now?
Regards
Chris
I checked how many calendar entries I have and it is ~5500 distributed over 5 calendars. That does not sound too much in my ears. So what to do now?
Indeed. Can you please post the logs as a gist so that we can be sure where the problem is? According to my calculations, ~ 30.000 entries (in 1 calendar) should be the limit.
The next goal for DAVdroid is to integrate it with ical4android. In the course of this, the sync. algorithm will also be overhauled. It seems reasonable for me that the deletion could be split into more transactions because it’s not an incosistent state when some entries are already deleted and some are not.