start of new DB design

[Maximilian Kossick]

On Wednesday 06 June 2007, Ian Monroe wrote:
> On 6/6/07, Maximilian Kossick <mkossick at gmx.de> wrote:
> > On Wednesday 06 June 2007, Ian Monroe wrote:
> > > I added a playlistcurrent table, and a set of tables to handle
> > > undo/redo. There are two types of tracks that can be in a playlist,
> > > those that are part of the collection and those that are not. So
> > > either trackid or externalid in playcurrent goes unused (externalid is
> > > a FK for the PK of playlistexternal, I just noticed the latter is
> > > missing.) This creates more complications in the undo/redo system.
> > >
> > > Any other ideas on how to handle that?
> >
> > How about using commands? I don't think we have to support undo/redo
> > across application restarts. That way you could simply store the changes
> > to the playlist in memory ( maybe limit the number of supported undo/redo
> > steps)
>
> Yes your right, I suppose it doesn't really need to be stored in the
> database. What do you mean by using commands?

The GoF command design pattern is designed for situation like this. 
(http://en.wikipedia.org/wiki/Command_pattern)

> Ian
> _______________________________________________
> Amarok-devel mailing list
> Amarok-devel at kde.org
> https://mail.kde.org/mailman/listinfo/amarok-devel


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/amarok-devel/attachments/20070606/6d73c80a/attachment.pgp