are you aware of the problems with google and microsoft .ics files? about davis HOT 10 CLOSED

hi,
I tested this solution as proposed in the other thread:
ALTER TABLE cards ALTER COLUMN carddata TYPE TEXT;
ALTER TABLE propertystorage ALTER COLUMN value TYPE TEXT;
ALTER TABLE calendarobjects ALTER COLUMN calendardata TYPE TEXT;
ALTER TABLE schedulingobjects ALTER COLUMN calendardata TYPE TEXT;

now the calendar entries are sync, but i am still checking the rest of things.

Lets see if this is not breaking anything

from davis.

FYI, It's merged in the master branch, and a release is planned for next week

from davis.

Hi

So you mean that we should change BYTEA to TEXT or something similar? You're using PostgreSQL, right? Because MySQL has LONGBLOB and it's a binary format too (which should then change to LONGTEXT).

I'm worried that the underlying sabre-io/dav code might break since it might expect a binary format and try to convert it. If you change the column type locally, converting your existing data, does it solve your bug?

from davis.

Yep, using postgres.
In the sabre bug thread they are suggesting that solution and they are willing to receive a PR with a patch to solve it, so it looks like they are not really interested on it. something that really puzzles me because they know they are incompatible with MS and Google and dont care. Those are major words.

But you have a very valid point, i could switch to mysql, my instance is not going to receive lot of user changing data at the same time, perhaps even not at the same hour so the advance concurrent writes that postgres features is a bit overkill, and if Mysql makes this problem dissapear even better.

I will test this in the evening so i can report it back to you. Perhaps the solution is as easy as to drop the possibility of postgres in this container README.

from davis.

In your use case, MySQL or PostgreSQL seem perfectly equivalent in terms of performance. But as I understand, you'll have the same problem in MySQL (since LONGBLOB is binary)

I'll try to change a column type and see what breaks

from davis.

Hi @thelittleblackbird 👋🏼
Did you run into any issues in the end? I've prepared the PR #111 to change the column types in Davis rather than in sabre/dav. I haven't seen any obvious problem but I couldn't test that much

Thanks

from davis.

Hi,

I didnt notice anything since the change.

But i also need to admit that due to familiar problems (my son got a broken arm with surgery) i didnt ahve a lot of time to extensively testing.

The day to day for my personal use is fairly ok, but again i need to check a bit more in detail before opening it to the rest of the users.

by the way, would it not be easier to drop the support of the databases which are using this configuration?

regards

from davis.

i didnt have a lot of time to extensively testing.

It's ok, don't worry, absolutely no pressure!

by the way, would it not be easier to drop the support of the databases which are using this configuration?

sabre-dav is officially only working with MySQL, which has BLOB columns too; I added (in Davis only) support for PostgreSQL and SQLite - and as per the original column definitions, they are using BLOB too for some tables. The only way forward if we want Davis to fix this bug is to migrate to (MEDIUM)TEXT, which is what the PR is doing. I'll try to do more testing if I find the time too, and will likely create a new release afterwards

from davis.

no worries, im glad to cooperate. :)

currently(for your information) i was able to sync successfully between google calendar, microsoft calendar, samsung calendar and thunderbird -> no issues found, all the options works including the exotic ones like recurrency, expiration and alarms.

I will ask some other persons to sign to the service and test in ios/apple environment and some other weird programs, to see if somebody is reporting something strange (no technical experts so perhaps they didnt even notice)

regards

from davis.

Release is done, I'm closing this for now, and if needed I'll iron out the details if we have more bug reports related to this

from davis.