Accessing uids

[Maximilian Kossick]

On Mon, Aug 11, 2008 at 6:57 PM, Ian Monroe <ian at monroe.nu> wrote:
> On Mon, Aug 11, 2008 at 11:37 AM, Jeff Mitchell
> <kde-dev at emailgoeshere.com> wrote:
>> Today I was working on making playlists AFT-happy, which has been a
>> thorn since 1.4 when it was impossible, and I ran into a stumbling block.
>>
>> SqlMeta lives inside src/collection/sqlcollection.  This is built
>> separately, not a part of amaroklib.
>>
>> I need to call the uid() method of SqlTrack, if the casting to SqlTrack
>> works.  But I can't cast it, because I can't tell it about SqlMeta.
>>
>> So I have the following options:
>>
>> 1) Move SqlMeta into src/meta and have it be built into amaroklib.  One
>> could argue that all known types of meta should live together so that
>> any part of Amarok can take advantage of specific features of different
>> Meta types.  One could also argue the opposite  :-)

Yes, one could:)

>> 2) Add a uid() function into Meta::Track.  While some may argue that
>> this may not really "belong" to a track, remember that uidUrl already
>> exists, which in many cases just puts this uid into a url format, so it
>> would essentially be a helper method so that one doesn't have to strip
>> the url-ness all over the place.  Most existing collections could simply
>> return the same as uidUrl().
>
> Reading your email triggered a thought in my sleep-addled brain. Add a
> FileTrackingCapability.

Do we really need another capability?
>
>> 3) Restructure things in the database such that UIDs aren't what's
>> stored, but rather uidUrls are stored in the uniqueid fields.  This
>> involves a lot more foo elsewhere, but is doable, if rather awkward and
>> somewhat of a waste of space.

Now we are getting somewhere. uidUrl is a unique identifier for a
track, which allows the collection that understands the uidUrl to
return the correct track if at all possible. Which is pretty much what
AFT does. Who cares about wasted space in a database these days?

Max