More > Media Center 14 (Development Ended)
Next -- Relational Database?
darichman:
I think whatever happens here should definitely be done in baby steps. As Jim has pointed out the database is streamlined and very efficient in its current incarnation. It would be foolish to disregard all that and sweep it all aside for something new and untested. That doesn't rule out extending things and testing the boundaries ;)
Matt, you've mentioned the possibility of simple inheritance. I think this is a really good idea. You've also mentioned some potential limitations or areas which may be ambiguous in its implementation and use...
--- Quote ---We don't keep a name and a unique user-manageable ID for each field (which I would argue is right). But this means if you set a relationship of "Store per album" and had ten Greatest Hits albums, it could get a little messy on those ten albums. We already have a runtime album analyzer that generates album IDs by looking at file paths and artist names, so it would help in this case. I'm not sure if the same problem would apply to relationships of other fields.
--- End quote ---
The "Greatest Hits" issue has always presented a problem - an album pane will not list separate entities for files with the same values populated for a field. There's nothing wrong with this, it's just how the program works, without separate "entries" for albums, as it were. This pops up with movies too... same release titles or re-releases which keep the same name. I think it's just something the user needs to be aware of (or even add a suffix at the end to differentiate, which is what I try to do). Hopefully the number of situations where this does arise is pretty small?
As far as how this affects inheritance... a dialogue box which confirms the changes might be useful: "Would you like to assign this file (these files) to the album Greatest Hits ([Album Artist])?" Album artist could be used to differentiate, if there is no separate Album ID to query? A "Compare Fields" dialogue would be really useful (remember aTagger?)
--- Quote ---Also, if you import a _new_ Aerosmith file with a different biography in the tag, should it inherit the existing data, overwrite the existing data for all the files in the relationship, or just be different?
--- End quote ---
This is how I envisaged how things might work (forget about parent/child fields if you wish and just pretend Nationality etc is inherited based on artist)
--- Quote ---1. Artists
The Parent Field is [Artist]
Child fields might include [Nationality] [Bio] [Formed] [Disbanded] [Discography] [Primary Genre] [Primary Styles] [Primary Moods] etc
So, once child fields have been assigned to the Parent Field as described above...
1. I import a file for tagging.
2. "Queen" could be added to the [Artist] field just as it is in the current version. Doing so would automatically create "Queen" as a taggable entity. It is an "Artist" which now exists in the database, just as a file does now.
3. Child fields [Nationality] etc could be filled in for "Queen" as per below
4. If I import a new file and tag [Artist] as "Queen", the file will inherit all of the Child Field values assigned above. Perhaps this could be accompanied by a "Would you like to assign this file to the Artist "Queen" and inherit all associated metadata?"
5. If I select a file already assigned to Queen with the artist metadata already filled out, and change the value of of a child field - [Nationality] for example - the user might receive the message: "Are you sure you which to change the Artist "Queen"? Note this change will affect all files assigned to the Artist "Queen"
This is the interface the user might see in the Tagging AW
> Artist: Queen
Bio: … (extended field)
Nationality: UK
Primary Genre: Pop/Rock
Primary Styles: Glam-Rock; Hard-Rock; Album-Rock etc
Members (a list field): Bon Scott; Malcolm Young
Formed: 1971 in London, England
Disbanded: 1995
> Album: A Night at the Opera
Album Genre: Pop/Rock
Album Year: 1975
Album Styles: Prog-Rock/ Art Rock etc
Album Moods: Witty; Theatrical; Elaborate etc
Label: Elektra
> Rest of the fields etc etc
Note that all of the fields listed above exist/can be created in the current MC - the key is that the child fields (tabbed) are all common to and inherited based on a singular Parent Field. I know some people get iffy about affecting files which aren't currently selected - but we're talking about a shift here from "changing the files" to "changing the artist to which the files belong" - ie any fields you assign as child fields of "Artist" should have the same values for all files belonging to that artist.
--- End quote ---
Matt, does the whole parent/child field make any sense from a development standpoint? Could it be implemented in such a way that it is only invoked when files are tagged or when database values are changed? So we're not talking so much about how the data is stored, just when it is stored.... I'm not sure if I'm explaining that very well - If MC knows that when I tag "Queen" or "Aerosmith" files that it needs to make the corresponding changes to relevant fields in*all* "Queen" or "Aerosmith" files, we haven't changed anything about how MC is actually storing the data (we've only told it to "tag these files too!"). This wouldn't cause any speed problems in normal views etc because the fields are stored as they are currently... the only time performance will take a hit is at the time of tagging (MC needs to query for all files with that [Artist])...
The other foreseeable issue here is list fields... simple inheritance like this won't allow me to tag "Tom Cruise" in a file with [Actor] = Tom Cruise;Nicole Kidman unless there was another layer to this.
Blobs might be cool. But again, baby steps... I don't know anything about software developing - I really want to be clear about that - I just know what I'd like to see functionally. Whatever way you guys can come up with to do that (if at all) I'm happy with... Development knows the software better than we do - what works and what will completely break the architecture of the program. The last thing any of us want is for MC to crash and burn because of big changes which came about at the insistence of demanding users. And I'm sure I belong in that category ;) Thanks for listening
rick.ca:
--- Quote ---I like that this approach fits nicely with the existing architecture and doesn't introduce any performance penalty in normal usage.
--- End quote ---
Okay. If I understand you correctly, there is no advantage to saving anything outside the current database structure. It could all be handled by the "Store this field per [category]" mechanism you mentioned. There would be the "tricky issues" you mentioned, but I assume these are things you believe could be overcome.
--- Quote ---Since you can make a view that groups by artist, you would effectively be able to look at the table of "Biography" values just by using such a view.
--- End quote ---
I see in Customize View I can select View as "[category] details." I've never tried that before, but I suppose it will give me something like the "blob table" view I was looking for. I'll have to study that more, and try to visualize how that might work. It would be nice if there were a "panes and [category] details" view available. I'm also not sure how this will work when the subject category is a list field (e.g., actors, directors). It appears that in a "[category] details" view, Name shows the unique values existing in [category]. I never noticed that before! 8)
Understandably, I cannot "rename" anything in these views. Would I be able to use the "Store this field per [category]" command?
Edit: Hmmm. For list values, I think not—that would require a relational database! ::)
hit_ny:
--- Quote from: Matt on June 13, 2009, 12:29:45 am ---If you make fields "Biography", "Date of Birth", "Country of Origin" and "Date of Death" and set them to be stored per artist it would be easy to use the fields in searches, for sorting, etc.
--- End quote ---
If i understood what Matt is saying then taking darichman's example with Queen
"Biography", "Date of Birth", "Country of Origin" and "Date of Death" would become child fields for the store 'by' or 'per' [Field] which is the parent field. In this case we choose to store by [Artist] which is the parent field.
But when adding a new Queen album if the user indicates the artist is queen, do the child fields automatically carry over ?
If they are blank one would expect this to be the case, if one of them is filled then the user is presented with a dialog to decide whether to
- inherit existing library data for that child field or
- keep seperate or
- overwrite existing data in the library for that child field
Functionally i think it would meet the aim of darichman's proposal ie A way to automatically assign several child fields by specifying just a parent field.
--- Quote from: darichman on January 08, 2008, 01:49:59 am ---I guess what I would like to be able to do is create a group, with it's own characteristics, and allow membership of files to that group so that they would then inherit those characteristics.
Files could naturally belong to more than one group (Album, Artist etc)
It would be a move to a true information database, rather than just a file database.
--- End quote ---
However they will limited to belonging to just one group here unless Matt allows to store 'per' more [Fields].
I also expect there would be a way to tell which [Fields] have been chosen for the parent, via the Action Window say.
What we need to do more is stress test this idea with more use-cases to understand better the limitations (if any) with it. This is purely from a user perspective as Matt already indicated that this approach is a feasible one :)
--- Quote from: Matt on June 13, 2009, 12:29:45 am ---I like that this approach fits nicely with the existing architecture and doesn't introduce any performance penalty in normal usage. (sets of relational fields would be a little slower, but sets are not too common)
--- End quote ---
JimH:
--- Quote from: newsposter on June 13, 2009, 12:03:48 am ---'Inventing' a decent, redundant, recoverable repository for blobs might be a good idea. It might already have been done in the many content management systems out there. But lets keep the hugeness external, not internal to the database.
--- End quote ---
How about one that mirrored the blobs to your private account on an Internet server?
rick.ca:
--- Quote ---How about one that mirrored the blobs to your private account on an Internet server?
--- End quote ---
OT: Why is there never a moderator around when you need one? ;D
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version