status of splitted configs for images and thumbnails databases

[Francesco Riosa]

     ... it's not good for release

I was programming to be able to fix the issues in the month release
cycle but had overestimated my free time and problems involved.

The mentioned issues are:

1) the user interface is suboptimal see attached screenshots, it should
at least provide a button to copy the options from one db config to the
other.
Better the widget should open with only one database config visible (if
database are currently the same) and go to a double set of options only
on user request.

2) Removal of mysql "internal database" option, this one has been
completely untested by me, I've strong feeling nobody is using it (even
under windows).
But we need a large survey on our users, because I do want to remove the
functionality /without/ migration plan. That's clearly not possible if
we have at least one user of internal database.
Rationale for removal is:
- the mysql forks are increasing, there is a real possibility that
distro will start using these forks, while most provide at least some
compatibility as client (for us it's abstracted by qtSql) no-one of the
executable tools will be guaranteed to be there and named the same.
- It's wrong, wrong, wrong, sqlite is an embedded database, has some
limitations and inconsistencies (see problems on btrfs) but it's born to
be embedded and does it well (it's the de facto standard). Mysql is a
system/global database - period -

3) there are isolation problems at connection level, some query intended
to run on thumbnails database are executed on the images one. While this
should be easy to fix make me think there are more issues waiting to be
discovered. Those require an in deep look which should be done relaxed
and not under release pressure.
https://bugs.kde.org/show_bug.cgi?id=281838

so it's ok if I do revert the few commits that are related to splitted
config and continue my work in sql/2.0 branch until it's more palatable?

migrating should be easy enough
https://bugs.kde.org/show_bug.cgi?id=281767
Comment #28
Comment #45

sorry,
Francesco


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

[Gilles Caulier-4]

2011/9/20 Francesco Riosa <[hidden email]>:

>    ... it's not good for release
>
> I was programming to be able to fix the issues in the month release cycle
> but had overestimated my free time and problems involved.
>
> The mentioned issues are:
>
> 1) the user interface is suboptimal see attached screenshots, it should at
> least provide a button to copy the options from one db config to the other.
> Better the widget should open with only one database config visible (if
> database are currently the same) and go to a double set of options only on
> user request.
>
> 2) Removal of mysql "internal database" option, this one has been completely
> untested by me, I've strong feeling nobody is using it (even under windows).
> But we need a large survey on our users, because I do want to remove the
> functionality /without/ migration plan. That's clearly not possible if we
> have at least one user of internal database.
> Rationale for removal is:
> - the mysql forks are increasing, there is a real possibility that distro
> will start using these forks, while most provide at least some compatibility
> as client (for us it's abstracted by qtSql) no-one of the executable tools
> will be guaranteed to be there and named the same.
> - It's wrong, wrong, wrong, sqlite is an embedded database, has some
> limitations and inconsistencies (see problems on btrfs) but it's born to be
> embedded and does it well (it's the de facto standard). Mysql is a
> system/global database - period -
>
> 3) there are isolation problems at connection level, some query intended to
> run on thumbnails database are executed on the images one. While this should
> be easy to fix make me think there are more issues waiting to be discovered.
> Those require an in deep look which should be done relaxed and not under
> release pressure.
> https://bugs.kde.org/show_bug.cgi?id=281838
>
> so it's ok if I do revert the few commits that are related to splitted
> config and continue my work in sql/2.0 branch until it's more palatable?

yes, fine for me.

Note that 2.2.0 release is planed at first week of october. the goal
is to provide a release each month with code stabilization and of
course new features (not too big to be testable (:=)))

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

[Francesco Riosa]

On 09/20/11 13:23, Gilles Caulier wrote:

> 2011/9/20 Francesco Riosa<[hidden email]>:
>>     ... it's not good for release
>>
>> I was programming to be able to fix the issues in the month release cycle
>> but had overestimated my free time and problems involved.
>>
>> The mentioned issues are:
>>
>> 1) the user interface is suboptimal see attached screenshots, it should at
>> least provide a button to copy the options from one db config to the other.
>> Better the widget should open with only one database config visible (if
>> database are currently the same) and go to a double set of options only on
>> user request.
>>
>> 2) Removal of mysql "internal database" option, this one has been completely
>> untested by me, I've strong feeling nobody is using it (even under windows).
>> But we need a large survey on our users, because I do want to remove the
>> functionality /without/ migration plan. That's clearly not possible if we
>> have at least one user of internal database.
>> Rationale for removal is:
>> - the mysql forks are increasing, there is a real possibility that distro
>> will start using these forks, while most provide at least some compatibility
>> as client (for us it's abstracted by qtSql) no-one of the executable tools
>> will be guaranteed to be there and named the same.
>> - It's wrong, wrong, wrong, sqlite is an embedded database, has some
>> limitations and inconsistencies (see problems on btrfs) but it's born to be
>> embedded and does it well (it's the de facto standard). Mysql is a
>> system/global database - period -
>>
>> 3) there are isolation problems at connection level, some query intended to
>> run on thumbnails database are executed on the images one. While this should
>> be easy to fix make me think there are more issues waiting to be discovered.
>> Those require an in deep look which should be done relaxed and not under
>> release pressure.
>> https://bugs.kde.org/show_bug.cgi?id=281838
>>
>> so it's ok if I do revert the few commits that are related to splitted
>> config and continue my work in sql/2.0 branch until it's more palatable?
>
>
> yes, fine for me.
>
> Note that 2.2.0 release is planed at first week of october. the goal
> is to provide a release each month with code stabilization and of
> course new features (not too big to be testable (:=)))
>
> Gilles Caulier

done, last commit
http://commits.kde.org/digikam/474fc91fcaffd20fb75d4c8e5a1312aa37543424

all commits:
7b7c708f5995ba0b39fb122b10b6dae8fe4027b3..474fc91fcaffd20fb75d4c8e5a1312aa37543424

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

[Gilles Caulier-4]

Note : if you have doubt about nex release date, look in top of root
digiKam CMakeLists.txt, date is set for tarball

Anyway, on website there is release plan (not always up to date)

http://www.digikam.org/drupal/about/releaseplan

Else, ask in this room (:=)))

Gilles

2011/9/20 Francesco Riosa <[hidden email]>:

> On 09/20/11 13:23, Gilles Caulier wrote:
>>
>> 2011/9/20 Francesco Riosa<[hidden email]>:
>>>
>>>    ... it's not good for release
>>>
>>> I was programming to be able to fix the issues in the month release cycle
>>> but had overestimated my free time and problems involved.
>>>
>>> The mentioned issues are:
>>>
>>> 1) the user interface is suboptimal see attached screenshots, it should
>>> at
>>> least provide a button to copy the options from one db config to the
>>> other.
>>> Better the widget should open with only one database config visible (if
>>> database are currently the same) and go to a double set of options only
>>> on
>>> user request.
>>>
>>> 2) Removal of mysql "internal database" option, this one has been
>>> completely
>>> untested by me, I've strong feeling nobody is using it (even under
>>> windows).
>>> But we need a large survey on our users, because I do want to remove the
>>> functionality /without/ migration plan. That's clearly not possible if we
>>> have at least one user of internal database.
>>> Rationale for removal is:
>>> - the mysql forks are increasing, there is a real possibility that distro
>>> will start using these forks, while most provide at least some
>>> compatibility
>>> as client (for us it's abstracted by qtSql) no-one of the executable
>>> tools
>>> will be guaranteed to be there and named the same.
>>> - It's wrong, wrong, wrong, sqlite is an embedded database, has some
>>> limitations and inconsistencies (see problems on btrfs) but it's born to
>>> be
>>> embedded and does it well (it's the de facto standard). Mysql is a
>>> system/global database - period -
>>>
>>> 3) there are isolation problems at connection level, some query intended
>>> to
>>> run on thumbnails database are executed on the images one. While this
>>> should
>>> be easy to fix make me think there are more issues waiting to be
>>> discovered.
>>> Those require an in deep look which should be done relaxed and not under
>>> release pressure.
>>> https://bugs.kde.org/show_bug.cgi?id=281838
>>>
>>> so it's ok if I do revert the few commits that are related to splitted
>>> config and continue my work in sql/2.0 branch until it's more palatable?
>>
>>
>> yes, fine for me.
>>
>> Note that 2.2.0 release is planed at first week of october. the goal
>> is to provide a release each month with code stabilization and of
>> course new features (not too big to be testable (:=)))
>>
>> Gilles Caulier
>
> done, last commit
> http://commits.kde.org/digikam/474fc91fcaffd20fb75d4c8e5a1312aa37543424
>
> all commits:
> 7b7c708f5995ba0b39fb122b10b6dae8fe4027b3..474fc91fcaffd20fb75d4c8e5a1312aa37543424
>
> _______________________________________________
> Digikam-devel mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-devel
>

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