View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000848 | MMW v4 | Main Panel/Toolbars/Menus | public | 2003-10-30 17:36 | 2006-10-31 12:49 |
| Reporter | rusty | Assigned To | |||
| Priority | immediate | Severity | feature | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Summary | 0000848: Some fields that are in the DB cannot be headings in the Explorer | ||||
| Description | The tracklist currently doesn't show several fields that many users would want to sort by: -Composer: for people storing classical music - it's important to be able to sort by this field. (Composer should appear following Artist, and be _off_ by default). -Original Year: for people storing classical music and for people who have many tracks from compilations. (Original Year should appear following Year and be _off_ by default). -Classifications (Tempo, Mood, Occasion, Quality): This is needed for people who want to sort by classification, or modify it live. (Classification fields should follow Ratings, and be _off_ by default). In addition, there are a couple of fields that the tracklist doesn't provide information about, that the user would not want to sort by but would: a) want to know whether the field is empty or not (e.g. via some sort of indicator that the field contains data _or_ via a portion of the actual text contained within the field). b) want to be able to view the contents of the entire field (e.g. via a tooltip or similar mechanism) -Comments -Lyrics: for people who use the lyrics functionality and want to know whether a track has lyrics or not. They won't actually edit the lyrics here--they just need to be able to know whether they exist or not. | ||||
| Additional Information | http://www.songs-db.com/forum/viewtopic.php?t=717 Needed for Classical Music Support: 0001545, 0000522 | ||||
| Tags | No tags attached. | ||||
| Fixed in build | |||||
|
|
This involves some changes to the database structure, so we'd be best off to make all the changes at once. Assigned to 'Rusty' to review all fields currently used and recommend which ones should be added to the main table. |
|
|
pushing--as discussed over IM, it's not too difficult to implement, but it's risky/potentially destabilizing. |
|
|
Updated the bug based on all comments to-date. Setting to 'immediate' because this should be done early in the alpha testing cycle due to the potential risk. |
|
|
Technical note: Originally (for several reasons) some track related fields weren’t stored in Songs table, namely some string fields were stored in AddSongInfo, integer fields in AddSongInfoInt and long strings (comments and lyrics) in Memos. This makes a problem because MM can’t read those fields using just one query and so they are retrieved only when needed (e.g. on showing Properties dialog). In order to fix these issues we should do the following: 1. Move fields from these 3 external tables (AddSongInfo, AddSongInfoInt, Memos) into Songs table. Each field will normally have its column in the Songs table. (see AIF constants (Additional Info Field) in DatabaseManage.pas). This requires a modification of SQLite schema in Mp3Consts.pas and later also implementation of proper update procedure for transfer of data from Access to SQLite DB. 2. Move these fields from TSongListData.AddInfo structure directly to TSongListData (requires some modifications across MM). See Mp3Consts.pas. 3. Add direct reading of these fields in CopyQueryToSongListData (TreeManage.pas) 4. Remove anything related to these 3 tables (AddSongInfo, AddSongInfoInt, Memos) in MM, because they will no longer be used. 5. Add necessary columns in ViewManage.pas so that user could show the columns directly in MM track list. This step is a little more complex, because also in-place editing of these fields must be added, etc. 6. Question is what to do with long strings (Comments and Lyrics). If user has a large collection and has these fields filled in (e.g. Lyrics for every track), it would occupy even tens of megabytes of RAM when e.g. in Title node. A possible approach is to always read only the first line of text (limited also by some 0000071:0000100-200 chars) in order to have something to show in the track list. Full data would be read only on request, e.g. if a script needs it, if user tries to edit or view track properties. Some kind of flag would specify whether full or shortened version of data is loaded. |
|
|
solved. |
|
|
1. There's a problem that DoubleQuotes() function isn't used, i.e. instead of TQ.SQL.Add (FormatPlus (', Publisher=''%s''', [SD.Publisher])); this should be used: TQ.SQL.Add (FormatPlus (', Publisher=''%s''', [DoubleQuotes(SD.Publisher)])); If it isn't done this way and e.g. a single quote is part of the string, there's a SQL error raised. 2. Currently UPDATE SQL command was added to StoreSongAddInfo(). However, for performance reasons it would be better to move this command to StoreSongIntoDB() (both under INSERT and UPDATE parts). |
|
|
done |
|
|
Shouldn't this be tagged as 'Resolved'? |
|
|
1. Comments and Lyrics columns are missing (not sure if it's some SVN version problem, I thought we discussed it and it was added). 2. Default width of new columns (Tempo, ...) is too small, even column title isn't visible. |
|
|
Tagging as Immediate, should be fixed prior the first MM 3.0 alpha release. |
|
|
solved |
