On 24/10/06, John Stowers <[EMAIL PROTECTED]> wrote: > > > > 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? > > 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. Dotan Cohen http://what-is-what.com/what_is/drm.html http://technology-sleuth.com/short_answer/why_are_internet_greeting_cards_dangerous.html _______________________________________________ F-spot-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/f-spot-list
