-
Notifications
You must be signed in to change notification settings - Fork 2.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
Cannot store complex custom Webdav property values + wrong values + Oracle failure #32670
Comments
We could attempt to convert the One challenge is that when reading it back we need to know it was a complex property and not a plain string. Might need an extra flag in the oc_properties table to mark complex properties. We could also look at how the Sabre default properties backend implementations handle this. |
This blocks Litmus tests for Oracle #32639 |
It should be possible to write an acceptance test that does a PROPPATCH of a custom property to cover this. |
GitMate.io thinks the contributor most likely able to help you is @DeepDiver1975. Possibly related issues are #11869 (webDAV failures), #12862 (Cannot get custom WebDAV properties back after setting them), #10247 (WebDAV permission attribute wrong), #6477 (Use WebDAV custom properties to tag/categorize files), and #256 (getetag property value in WebDAV response lacks quotes). |
Acceptance test to trigger this here: #32675 |
might need a new column with a flag that tells us whether the value is complex or not ? |
Oracle DB support is a blocker for the public release, IMO. Putting this into "development" milestone therefore. Can you estimate the effort, please? |
@VicDeo can you estimate ? |
@pmaier1 note: so far there is no known app out there that actually use the feature in question. This is only about Webdav compliance as tested by litmus. |
@PVince81 the issue that we had in files_lifecycle is a wrong escaping of our custom Properties in the query builder.
|
I might be wrong but it is supposed that property should know how convert itself into something usable for DB: No idea for estimates. Let's say 2md |
oops. I'm wrong (but not 100%). type is stored next to the property itself and the PROPFIND value is returned according to the type: |
In PHP 7.4 when we run the scenario for this and with MySQL DB:
and and the backend throws an exception:
Maybe this is related to https://wiki.php.net/rfc/tostring_exceptions The scenario was passing on PHP 7.* before 7.4 |
And litmus fails in PHP 7.4
owncloud.log contains:
This is the same sort of object __toString problem. |
This stops litmus passing on MySQL/MariaDB with PHP 7.4 |
Oracle failure is addressed in #37298 |
I added this to the |
Steps
<?xml version="1.0" encoding="utf-8" ?><propertyupdate xmlns='DAV:'><set><prop><t:valnspace xmlns:t='http://example.com/neon/litmus/'><foo xmlns='http://bar'/></t:valnspace></prop></set></propertyupdate>
which sets a complex valuecurl -k -D - -u admin:admin -X PROPPATCH -H "Content-Type: text/xml" --data-binary "@proppatch.xml" "http://localhost/owncloud/remote.php/webdav/test"
<?xml version="1.0"?><a:propfind xmlns:a="DAV:" xmlns:oc="http://owncloud.org/ns"><a:prop><t:valnspace xmlns:t='http://example.com/neon/litmus/'/> </a:prop></a:propfind>
curl -k -D - -u admin:admin -X PROPFIND -H "Content-Type: text/xml" --data-binary "@propfind-oracle.xml" "http://localhost/owncloud/remote.php/webdav/test"
Expected result
oc_properties table must contain
<foo xmlns='http://bar'/>
or something alike.the PROPFIND response should contain
<foo xmlns='http://bar'/>
.Actual result
With MySQL
oc_properties table contain the string "Object" as value.
the PROPFIND response contains
<x1:valnspace xmlns:x1="http://example.com/neon/litmus/">Object</x1:valnspace>
With Oracle
PROPPATCH fails:
This is likely because the complex value cannot be converted to string properly, so some process in Doctrine attempts to transform it to string. In MySQL it becomes
Object
, with Oracle it becomes an empty string or the weird{}
value in the query.Version
ownCloud 10.0.10 RC1
Discovered while debugging Oracle Litmus failure with PROPPATCH, see #32639 (comment)
Not sure if this ever worked before.
I'm really surprised Litmus lets this pass for MySQL.
I suspect this never worked before as we never really tested with complex properties.
The text was updated successfully, but these errors were encountered: