We need to store the owner of a file in the db to do efficient queries
on the owner of a file. Without this we need to construct fill paths for
each file id in the table and see who the owner of a file is. Which does
not scale.
</field>
<!-- Foreign Key users::uid -->
+ <!-- This is the initiator of the share -->
<field>
<name>uid_owner</name>
<type>text</type>
<length>64</length>
</field>
+ <!-- Foreign Key users::uid -->
+ <!-- This is the owner of the file, this can be
+ different from the initiator of the share.
+ The naming is subobtimal but prevents huge
+ migration steps -->
+ <field>
+ <name>uid_fileowner</name>
+ <type>text</type>
+ <default></default>
+ <notnull>false</notnull>
+ <length>64</length>
+ </field>
+
<!-- Foreign Key share::id or NULL -->
<field>
<name>parent</name>
// We only can count up. The 4. digit is only for the internal patchlevel to trigger DB upgrades
// between betas, final and RCs. This is _not_ the public version number. Reset minor/patchlevel
// when updating major/minor version number.
-$OC_Version = array(9, 0, 0, 2);
+$OC_Version = array(9, 0, 0, 3);
// The human readable string
$OC_VersionString = '9.0 pre alpha';