ratings and scores use 0 for default value

[Dan Meltzer]

On Sun, Nov 30, 2008 at 10:04 AM, Jeff Mitchell
<kde-dev at emailgoeshere.com> wrote:
> Mark Kretschmann wrote:
>> On Sun, Nov 30, 2008 at 2:17 AM, Caleb Cushing <xenoterracide at gmail.com> wrote:
>>> https://bugs.kde.org/show_bug.cgi?id=172112
>>>
>>> unrated and unscored should be null values in the database, not having
>>> them as null creates a problem when ever you want to set up a playlist
>>> that includes greater than certain ratings or scores. and unrated
>>> track should not be considered less than a rated track.
>>>
>>> sql wise this is as simple as making sure the default value when
>>> creating tracks is null.
>>
>> Well, do you have a patch for this? Otherwise I see no point in
>> bringing up the topic here on the dev list.
>>
>
> He brought it up here because I asked him to.  It will be harder to
> change the sql schema after 2.0 than before it, so I thought we may want
> to look at getting a fix in.

Mmm, you know what I'm going to say about that...

We're going to want to change tables down the road probalby anyways...
so we'll have to come up with a good way of doing updates (probably
something like quassel does, I imagine.  I cannot think of any
possible justification for making this change between a release
candiate and the final release.  The idea of unrated ==0 is used
throughout the amarok code, and it would be relativaly easy for
regressions to appear.
>
> Probably, the fix is to either modify the schema or the query (so that
> the query uses values of 0 as acceptable for all values > X).

... Though modifying the query would probably be less
regression-likely... though it has the (probably minor) side effect of
people who explicity rate their songs as 0 still getting them... The
schema change is probably the best idea, for down the road, as unrated
should probably be thought of as different than 0, both in star-images
and in the code
>
> The second one might be less intrusive and probably not that hard a fix
> (Caleb, any help there?); the first fix would be more correct (unless it
> would make our code more difficult elsewhere).
>
> --Jeff
> _______________________________________________
> Amarok-devel mailing list
> Amarok-devel at kde.org
> https://mail.kde.org/mailman/listinfo/amarok-devel
>