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

["Aigars Mahinovs" <aigarius gmail com>]

On 10/24/06, Dotan Cohen <dotancohen gmail com> wrote:
> > > 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?
> >
> > I dont think that this approach is solving the problem, nor is it
> > planning intelligently for the future. While the approach may work, I
> > think that moving feature X as field Y into the database *each time*
> > something new is added is not very clean.
>
> The idea is to give F-Spot the flexibility to add new features without
> having to worry about a new database format. Remember, it's still beta
> software, and being developed rather quickly.

Such change is not too useful from the database mainterance point of
view. All fileds need names that reflect their content. If we do not
know the content of a future field, we can not know its future name,
so in the future we would still need to rename the field to its real
name. That is no different to adding a new field at that point.

Making databases of data in the form of: objectid INT, propertyname
VARCHAR(255), propertyvalue VARCHAR(255) would be even worse as no
proper selects and joins of such data would be possible. All benefits
of using a database would be wasted (including indexing).

I suggest that database schema versioning is abided to and f-spot
would have a code section that read similar to:
read_database_schema_version()
if schema_ver > my_schema_ver then abort( too new )
switch schema_ver:
 case 1:
   /* Code to upgrade from v1 to v2 */
 case 2:
   /* Code to upgrade from v2 to v3 */
  ...
  case my_schema_ver:
  /* start as usual */

This would assure safe and predictable upgrading from any database
version to the latest one. The database must contain a special field
describing the database schema version, of course.

Note: I haven't checked if anything of this is already in plae in f-spot.

--
Best regards,
   Aigars Mahinovs        mailto:aigarius debian org
#--------------------------------------------------------------#
|     .''`.         Debian GNU/Linux              LAKA         |
|    : :' :      http://www.debian.org  &  http://www.laka.lv  |
|    `. `'                                                     |
|      `-                                                      |
#--------------------------------------------------------------#