-
-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow DAV Object properties #30368
Allow DAV Object properties #30368
Conversation
public function run(IOutput $output) { | ||
$query = $this->connection->getQueryBuilder(); | ||
$updated = $query->delete('properties') | ||
->where($query->expr()->eq('propertyname', $query->createNamedParameter(self::RESOURCE_TYPE_PROPERTY))) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Important note : I chose to delete only {DAV:}resourcetype
properties because they were the ones involved in the calendar issue, but there might be more concerned propertyname
s.
I didn't want to directly remove the condition on propertyname
in case there's some legitimate Object
propertyvalue
s, (which seems however unlikely).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Found two extra property names affected:
{http://calendarserver.org/ns/}me-card
{urn:ietf:params:xml:ns:caldav}schedule-calendar-transp
aa2bfe9
to
56bafc3
Compare
56bafc3
to
82a14e6
Compare
I think this is a better way to handle things than converting to string #30771 |
82a14e6
to
175fb56
Compare
The current implementation only saves them as string. It seems they can be more complex than that, and that objects were saved directly. You may find such objects saved in some production databases by executing: ```sql SELECT * from oc_properties where propertyvalue = 'Object'; ``` This commit adds a repair job to clean all of these "broken" properties values, adds a new database column to save the type of the property, and handles converting from and to correct values. Implementation is very similar to SabreDAV's own PDO backend: https://github.com/nextcloud/3rdparty/blob/4921806dfb1c5c309eac60195ed34e2749baf3c1/sabre/dav/lib/DAV/PropertyStorage/Backend/PDO.php Signed-off-by: Thomas Citharel <tcit@tcit.fr>
175fb56
to
bd8b213
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense, old known issue 👍
Also will likely solve issues with Oracle when storing complex props as I rembember issues there
25 only as it adds a new column and might be an expensive upgrade |
The propertyvalue column can contain null 0x00 characters values because of serializing PHP objects since #30368. This truncates data in text fields, but not blob fields. We start by removing invalid value and altering the column to match the new type. That's what Sabre PDO's being doing in the first place 🙈 Closes #37754 Signed-off-by: Thomas Citharel <tcit@tcit.fr>
The propertyvalue column can contain null 0x00 characters values because of serializing PHP objects since #30368. This truncates data in text fields, but not blob fields. We start by removing invalid value and altering the column to match the new type. That's what Sabre PDO's being doing in the first place 🙈 Closes #37754 Signed-off-by: Thomas Citharel <tcit@tcit.fr>
The propertyvalue column can contain null 0x00 characters values because of serializing PHP objects since #30368. This truncates data in text fields, but not blob fields. We start by removing invalid value and altering the column to match the new type. That's what Sabre PDO's being doing in the first place 🙈 Closes #37754 Signed-off-by: Thomas Citharel <tcit@tcit.fr>
The propertyvalue column can contain null 0x00 characters values because of serializing PHP objects since #30368. This truncates data in text fields, but not blob fields. We start by removing invalid value and altering the column to match the new type. That's what Sabre PDO's being doing in the first place 🙈 Closes #37754 Signed-off-by: Thomas Citharel <tcit@tcit.fr>
The propertyvalue column can contain null 0x00 characters values because of serializing PHP objects since #30368. This truncates data in text fields, but not blob fields. We start by removing invalid value and altering the column to match the new type. That's what Sabre PDO's being doing in the first place 🙈 Closes #37754 Signed-off-by: Thomas Citharel <tcit@tcit.fr>
The current implementation only saves them as string. It seems they can be more complex than that, and that objects were saved directly.
You may find such objects saved in some production databases by executing:
This seems to cause issues in some particular cases (nextcloud/calendar#3551) like the calendar trashbin because of things like this and (apparently ?) Apple devices:
server/apps/dav/lib/CalDAV/CalDavBackend.php
Lines 3208 to 3211 in 0b01103
This commit adds a repair job to clean all of these "broken" properties values, adds a new database column to save the type of the property, and handles converting from and to correct values.
Implementation is very similar to SabreDAV's own PDO backend: https://github.com/nextcloud/3rdparty/blob/4921806dfb1c5c309eac60195ed34e2749baf3c1/sabre/dav/lib/DAV/PropertyStorage/Backend/PDO.php
Fixes nextcloud/calendar#3858 (comment)