[Owncloud] Core db schema broken and unfixable without new installation

[Jörn Friedrich Dreyer]

Which database are you using? And which tables lack an autoincrement id and a manually defined Index, too? AFAIR the core database schema defines indexes for all full table scans that appear in the Core code. A customer found some missing ones in OC4.5 but they were missing because I backported the new Gallery to 4.5 for them. OC5 I think is all peachy.

With regard to foreign keys let me tell you that from a practical perspective you don't want to have them defined in your database for the following reason: at some point in time you will want to store a partially complete or inconsistent model in your database (eg, because you need to save work in progress). That will be the time you curse your foreign keys, because they were invented to prevent you from doing that. Especially migrations are a lot easier when you can leave depending tupels in a table ... Just my 2 cents.



Bernhard Posselt <nukeawhale at gmail.com> schrieb:

>On 03/18/2013 07:29 PM, Daniel Danger wrote:
>> Hi,
>>
>> On 03/18/2013 07:05 PM, André Schild wrote:
>>> Am 18.03.2013 18:49, schrieb Bernhard Posselt:
>>>> On 03/18/2013 06:48 PM, Thomas Tanghus wrote:
>>>>> On Monday 18 March 2013 17:15 Bernhard Posselt wrote:
>>>>>> I've tried adding those fields and removing the primary key
>values from
>>>>>> the indices fields (why the fuck are they even in there!?)
>> Defining a primary key in the MDB2 Schema definition has some
>pitfalls.
>> quoting from
>>
>https://raw.github.com/pear/MDB2_Schema/master/docs/xml_schema_documentation.html
>> :
>> 1) <autoincrement>: "Boolean flag property that specifies whether the
>> field should be an auto incrementing not null integer field with a
>> primary key."
>> 2) <primary>: "Boolean flag property that specifies whether the
>> combination of the values of the index fields on each row of the
>table
>> should be a primary key."
>>
>> Keep in mind, that the autoincrement tag is only defined within a
>> <field> declaration and the primary tag is only defined within a
><index>
>> declaration.
>>
>>>> Yeah but if the field that the index refers to is a primary key,
>then
>>>> so is the index. Or am i wrong?
>>> Some databases automatically create indexes for PK fields,
>>> for others you have to create a index for PK fields.
>> For all intends and purposes the primary key IS an index. So it makes
>> sense to define it as an index. (in some cases you need the primary
>key
>> to be composed of more than one field, in which case this is the only
>> way to define it).
>>
>>> In a DB schema PK fields makes most sense when you then also use
>them in
>>> foreign keys, that way your data integrity
>>> is protected by the database.
>> Well, foreign keys are not used in owncloud. myisam doesn't support
>> them. And there are strong advocates for not dropping myisam support.
>>
>> HTH
>> Daniel
>> _______________________________________________
>> Owncloud mailing list
>> Owncloud at kde.org
>> https://mail.kde.org/mailman/listinfo/owncloud
>ok, just checked: unique, index and autoincrement gets transformed to 
>primary key. Well this is awkward. That doesnt change the fact that the
>
>schema is missing tons of primary keys though.
>_______________________________________________
>Owncloud mailing list
>Owncloud at kde.org
>https://mail.kde.org/mailman/listinfo/owncloud

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/owncloud/attachments/20130318/03f6afb3/attachment.html>