Re: Goal #6 : Rating - 326561 Test/Review/Comment

["Dotan Cohen" <dotancohen gmail com>]

On 18/10/06, Bengt Thuree <bengt thuree com> wrote:
> Hi Guys
>
> I sent out the mail about the next goal (#7 Job Scheduler 337724 [1]) the
> other day, and are looking forward to see some more tests / reviews on it.
> Some people have already signed up for the bugzilla bug which is great :)
> Thanks
>
> But, we also still have the Rating patch to review.
> http://bugzilla.gnome.org/show_bug.cgi?id=326561
>
> The reason we did not accept it as it was was for two reasons (mainly one)
> 1) This patch do change the database format.
> 2) We do not have a good GUI to filter based on rating.
> Of the two above, the critical one is the database change.
>
> We decided this patch needed a bit more time for people to think of any
> possible side effects due to this change. So have a look at the bugzilla
> [2] comments, look at the code, look at the screen-shots, apply the patch,
> try it out (with the --basedir /tmp --photodir /tmp option), and see if
> you have any positive or negative experiences.
>
> Do report your thoughts to bugzilla though, so we all know and can discuss
> it. (if impossible to use bugzilla, send a mail to this list)
>
> One thought for instance was about rating per versions, which sounds good,
> but since tags are for photo why should the rating be per version?
>
> Apparently this patch do not apply cleanly to CVS anymore, but that should
> be fixed a bit later today.
>
> Bengt
> [1] http://bugzilla.gnome.org/show_bug.cgi?id=337724
> [2] http://bugzilla.gnome.org/show_bug.cgi?id=326561

I know that I'm a bit late, but I've been real hard pressed with studies...

If the major problem is the database change, then I think that the
time should be taken to reconsider the other database problems, and to
make a revised database forward- compatible with future versions.
Might I propose this:

A new database format that contains the needed fields for the Rating
patch, and also a few as-yet unneeded fields. I figure that four ints,
four varchars, and two text fields should get us past the next four or
five database change requirements that future patches may need. Is
there any downside to having these new redundant, as-yet unused
fields?

Also, I believe that the database location should be changed to the
photodir location. This would allows for three advantages:
1) F-spot could look in photodir for the database. If it finds it,
then it knows that the database is of the new format. If not, then it
will look in ~/.gnome2/f-spot, and create a new database in photodir
of the new format.
2) The new location would allows for multiple Library support. I know
that little work has been done on this, but here is the opportunity to
set the stage for this. I myself am looking forward to this
enhancement, assuming that it will one day be.
3) This would make testing new F-Spot builds easier and safer. If I
see that I'm in my 'real' photo collection, I know that I'm also on my
real database. There is no chance of me testing an F-spot build on my
real database by accident.

Anybody agree/ disagree?

Dotan Cohen

http://slashedot.org
http://what-is-what.com/what_is/text_editor.html