We need some way to filter recordings. Currently the "Edit track/add recording"
dialog shows all available Recordings, which is both confusing and slow in a
large database. Not sure how we want to do this, both from a usability and
technical perspective.
Here's a quote from the discussion forum (by Erland):
From a user perspective, I think the logical way to create a new Release for me
would be:
1. Create the Release
2. Specify the track number and track title
3. If there already is a Work.name or Recording.name in the database with the
same title, give me an option to:
- Create a new Recording and new Work if none of the items in the list matches
the correct Work
- Create a new Recording tied to an existing Work if one of the items in the
list matches the correct Work
- Create a new Recording but link it with a mixOf relation to an existing
Recording if one of the items in the list matches the original recording.
To make the list understandable, it's not enough to just show the Work.name or
Recording.name, we need to show more information, something like:
Release title 1, Artist 1, Work 1, Composer 1
Release title 1, Artist 1, Recording (mixOf), Work 1, Composer 1
Release title 2, Artist 1, Work 1, Composer 1
Release title 3, Artist 2, Work 2, Composer 2
Where there are two Works with same title where the first three rows represent
one Work and the last is a second Work.
From an API perspective we still have a small problem, at the moment we don't
have any way to return the contributors together with the Work or Recording
through the management API since we made the contributor a completely separate
entity, so I think we may want to do the query for recordings through the query
API. The query API still doesn't support returning contributors together with
works but we probably have to add that for other scenarios as we are going to
need track lists similar to the above information in the browse menus.
I also think we in the above list want to show aggregated contributor
information and not just the contributor directly tied to a specific recording
or work. For example, I'd like the artist name to show up in the list
independent if it's related to the Release, Recording or Recording Session. If
we want to do this we need to do this query through the query API because the
management API will only return direct contributor relations and not the
indirectly aggregated ones.
So I guess what I'm saying is that currently you will only have server API
support for querying recordings and get back a simple list with just the
Recording (and related Work) without any information about contributors. This
is probably good enough now initially and we can switch it to use the query API
when we have added better support for getting contributor information in it.
Finally, it might be worth to mention that currently the search relations used
in the query API aren't updated based on changes through the management API, so
if you get strange effects where you have added/modified some data and it
doesn't show up in queries, it might be related to this. We need to fix this on
the server side of course, it's just that I haven't had the time to find out
exactly how to do it yet.
Original issue reported on code.google.com by peer.tor...@gmail.com on 4 Jun 2011 at 2:23
Original issue reported on code.google.com by
peer.tor...@gmail.comon 4 Jun 2011 at 2:23