Schema update in branch

[Marcel Wiesweg]

Hi,

Sometimes within the next few days, a schema update (mostly as proposed in the
wiki page, with some additional fixes) will be committed to the GSoC branch.
This will update the database schema from version 5 to 6.

Important: The database remains backwards compatible, i.e., you can continue
to use it with digikam 0.10.0 - 1.4.

For users of the branch within the next two months, a backup copy may be
advisable in case anything goes wrong or we forgot important things, but I
hope we did not.

Tables and a few indices are added, none if the existing tables are changed.
For MySQL, there is a bugfix with the field length for the uniqueHash, which
was cut until now.

Marcel
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Michael G. Hansen]

On 07/03/2010 12:46 PM, Marcel Wiesweg wrote:
> Sometimes within the next few days, a schema update (mostly as proposed in the
> wiki page, with some additional fixes) will be committed to the GSoC branch.
> This will update the database schema from version 5 to 6.

Sounds good! I tried to come up with some property names and added them
to the wiki page. [1]

So far, I have only one open question: How do we store region
annotations which are not associated with a tag? For example, if the
user describes something other than a person, for which he just wants
some sort of description, but no tag?

Michael

[1] http://community.kde.org/Digikam/GSoC2010/DatabaseChanges
--
Michael Hansen - [hidden email]
http://www.pfna.de/
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

> Sounds good! I tried to come up with some property names and added them
> to the wiki page. [1]
>
> So far, I have only one open question: How do we store region
> annotations which are not associated with a tag? For example, if the
> user describes something other than a person, for which he just wants
> some sort of description, but no tag?

What's the usecase?

This is the kind of stuff which you dont think about when designing the SQL
tables.

Normally, this would be a comment/description and should go into the
ImageComments table.
Any of the traditional types of comment - Comment, Headline, Title - do not
have associated region information.
We can add a type of comment which comes with region information. This
information can be stored
a) in a separate field in the table. Problem: would this field be allowed for
a normal comment, which usually applies to the whole picture? Second problem:
The UNIQUE clause would allow only one of such entries per picture
b) with the current schema, in XML in the comment field. Problem: Once again,
the UNIQUE clause interferes, limiting to one entry per picture and author.

The ImageProperties table has a UNIQUE clause as well.

We could abuse the ImageTagProperties table, with a tagid of 0. But here,
there is no author / date information.



>
> Michael
>
> [1] http://community.kde.org/Digikam/GSoC2010/DatabaseChanges

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Johannes Wienke-3]

Am 04.07.2010 16:30 schrieb Marcel Wiesweg:

>
>> Sounds good! I tried to come up with some property names and added them
>> to the wiki page. [1]
>>
>> So far, I have only one open question: How do we store region
>> annotations which are not associated with a tag? For example, if the
>> user describes something other than a person, for which he just wants
>> some sort of description, but no tag?
>
> What's the usecase?
>
> This is the kind of stuff which you dont think about when designing the SQL
> tables.
>
> Normally, this would be a comment/description and should go into the
> ImageComments table.
> Any of the traditional types of comment - Comment, Headline, Title - do not
> have associated region information.
> We can add a type of comment which comes with region information. This
> information can be stored
> a) in a separate field in the table. Problem: would this field be allowed for
> a normal comment, which usually applies to the whole picture? Second problem:
> The UNIQUE clause would allow only one of such entries per picture
> b) with the current schema, in XML in the comment field. Problem: Once again,
> the UNIQUE clause interferes, limiting to one entry per picture and author.
>
> The ImageProperties table has a UNIQUE clause as well.
>
> We could abuse the ImageTagProperties table, with a tagid of 0. But here,
> there is no author / date information.

To my mind this is something generally not covered by the db so far. An
annotated region is definitely more than a normal comment. So this needs
a completely new table that associates each picture with n such region
annotations (1-N relation).

Johannes


_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

for me, to update db in gosc branch is fine. this code is not yet in production
gilles

2010/7/4, Johannes Wienke <[hidden email]>:

> Am 04.07.2010 16:30 schrieb Marcel Wiesweg:
>>
>>> Sounds good! I tried to come up with some property names and added them
>>> to the wiki page. [1]
>>>
>>> So far, I have only one open question: How do we store region
>>> annotations which are not associated with a tag? For example, if the
>>> user describes something other than a person, for which he just wants
>>> some sort of description, but no tag?
>>
>> What's the usecase?
>>
>> This is the kind of stuff which you dont think about when designing the
>> SQL
>> tables.
>>
>> Normally, this would be a comment/description and should go into the
>> ImageComments table.
>> Any of the traditional types of comment - Comment, Headline, Title - do
>> not
>> have associated region information.
>> We can add a type of comment which comes with region information. This
>> information can be stored
>> a) in a separate field in the table. Problem: would this field be allowed
>> for
>> a normal comment, which usually applies to the whole picture? Second
>> problem:
>> The UNIQUE clause would allow only one of such entries per picture
>> b) with the current schema, in XML in the comment field. Problem: Once
>> again,
>> the UNIQUE clause interferes, limiting to one entry per picture and
>> author.
>>
>> The ImageProperties table has a UNIQUE clause as well.
>>
>> We could abuse the ImageTagProperties table, with a tagid of 0. But here,
>> there is no author / date information.
>
> To my mind this is something generally not covered by the db so far. An
> annotated region is definitely more than a normal comment. So this needs
> a completely new table that associates each picture with n such region
> annotations (1-N relation).
>
> Johannes
>
>

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

>
> To my mind this is something generally not covered by the db so far. An
> annotated region is definitely more than a normal comment. So this needs
> a completely new table that associates each picture with n such region
> annotations (1-N relation).

Yes, I agree.

If we have a usecase right now, we can include it in the current schema
update; but if noone has invested thoughts how to do it right, we should
postpone. A backwards-compatible schema update like this is easily done.

Marcel
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Michael G. Hansen]

On 07/04/2010 05:45 PM, Marcel Wiesweg wrote:

>
>>
>> To my mind this is something generally not covered by the db so far. An
>> annotated region is definitely more than a normal comment. So this needs
>> a completely new table that associates each picture with n such region
>> annotations (1-N relation).
>
> Yes, I agree.
>
> If we have a usecase right now, we can include it in the current schema
> update; but if noone has invested thoughts how to do it right, we should
> postpone. A backwards-compatible schema update like this is easily done.

Sounds good! I just wanted to make sure we don't miss it ;-)

Michael
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel