View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0008970 | MMW v4 | DB/FileMonitor | public | 2012-01-16 09:56 | 2013-01-10 15:00 |
| Reporter | zvezdan | Assigned To | |||
| Priority | high | Severity | minor | Reproducibility | N/A |
| Status | feedback | Resolution | open | ||
| Target Version | 4.1.1 | ||||
| Summary | 0008970: Suggestion how to add almost unlimited numer of tags/fields with very little DB modifications | ||||
| Description | With a very little intervention on the database you could extend your proposal for new tags in 6218 topic to allow not only manipulation of the new fields when reading/writing tags from files, but also in many other situations as I described at the 7223 topic. OK, that my previous suggestion assumed that you add several new custom fields to the Songs table which you obviously don't want. However, I have two new proposals and I will try to explain DB and API approach using two new custom fields: Country and Language, both of them could be multi-item, e.g. Country could be USA;Mexico and language could be English;Spanish. 1. proposal: storing multiple user fields into some existing unused field from the Songs table, e.g. Remixer. Syntax of the data stored in that field in DB could be e.g. "Country:USA;Mexico/Language:English;Spanish" with the named parameters. Your suggested new GetFieldValue/SetFieldValue methods could be used to get those parts using API, e.g. GetFieldValue("Country") and SetFeildValue("Country", "USA;Mexico"). That is not very elegant solution because it requires parsing of that field, but that task would be left to you MM developers to do it internally and scripters would have a simple API interface to deal with those new fields. 2. proposal: is much more elegant, but it requires one new table added to the database, let's call it Tags. With that suggestion you would store the new custom fields into the List and ListsSongs tables beside of the existing Tempo, Mood, Occasion and Quality. Songs: ID = 123 ListsSongs: ID = 101, IDSong = 123, IDListType = 5 (or higher), IDList = 456 ID = 102, IDSong = 123, IDListType = 5, IDList = 457 ID = 103, IDSong = 123, IDListType = 6, IDList = 458 ID = 104, IDSong = 123, IDListType = 6, IDList = 459 Lists: ID = 456, IDListType = 5, TextData = "USA" ID = 457, IDListType = 5, TextData = "Mexico" ID = 458, IDListType = 6, TextData = "English" ID = 459, IDListType = 6, TextData = "Spanish" Here is the only new thing, the Tags table: ID = 11, IDListType = 5, TagName = "Country" ID = 12, IDListType = 6, TagName = "Language" The API in this proposal would be the same as in the previous one with just two new methods. As you could see, both proposals ensures almost unlimited number of new fields. The benefit is that we scripters would have the official way to use them, not clashing each other with the limited 5 custom fields, and we would have simple API interface with just two new methods already suggested by you. I didn't mention anything about reading/storing of those fields into files, that is something that you should decide what would be the best. Maybe you could implement both of my proposals in the same way as you already store e.g. the same Tempo string into the Songs table and the Lists/ListsSongs tables. In that case you could read/write all those fields from/to the one new unused tag frame like TPE4. The user presentation of those fields would be somewhat more problematic. The scripters could modify the Properties dialog to allow editing of those fields, but their display in the main tracklist is not currently possible. However, you could add one new field to the masks syntax corresponding to the DB field that I suggested in the first proposal and the users could use that field in the Summary column, specifying the mask e.g. <CustomTag>. Even better, you could enhance that to <CustomTag:Country> with the specified name of the new field. Such mask's field could be used everywhere where you use the masks, e.g. for Auto-organize, not limited only for specifying the Summary column. | ||||
| Additional Information | http://www.mediamonkey.com/forum/viewtopic.php?p=328087#p328087 | ||||
| Tags | No tags attached. | ||||
| Fixed in build | |||||
