This automation was originally cooked up in response to a question about how to keep playlists automatically sorted. But it is also very useful in certain business applications.
The QUEUEPOS maintains an ordered list. It is best shown with an example. Consider this table:
| Song | Playlist Spot |
|---|---|
| The Desert Is On Fire | 1 |
| Sultans of Swing | 2 |
| Nancy Whiskey | 3 |
| Prophecies | 4 |
| Battle of Evermoer | 5 |
Now we wish to insert a new song, "Romeo and Juliet" at spot number one. The Andromeda philosophy says that the application should have to do only one insert, and the rest of the playlist should be automatically updated. After a single insert of the new song, we want the playlist to look like this:
INSERT INTO SONGS (songname,spot) values ('Romeo and Juliet',1);
| Song | Playlist Spot |
|---|---|
| Romeo and Juliet | 1 |
| The Desert Is On Fire | 2 |
| Sultans of Swing | 3 |
| Nancy Whiskey | 4 |
| Prophecies | 5 |
| Battle of Evermoer | 6 |
To make the above playlist, we would do the following:
column songname:
type_id: vchar
colprec: 100
description: Song Name
column spot:
type_id: int
description: Position in Playlist
table songs:
module: music
description: Songs
column songname:
primary_key: Y
uisearch: Y
column spot:
uisearch: Y
auto: queuepos
Once we have set up this table, every time a user inserts or updates a row with a value of SPOT that matches an existing row, the existing row has its value bumped up by 1. If this causes it to match an existing row, that row gets bumped up by 1, and so forth.
In the example above, the order of the list is maintained on the entire table. But sometimes you want to have sub-lists within a table. For instance, perhaps we have a variety of playlists and we want to maintain order within them, but we do not want them to interfere with each other. In this case we add the "auto_formula" property that names a parent table. The QUEUEPOS values will then be maintained only for rows that match on the same value of the foreign key.