RE: [mylar-dev] changes to AbstractQueryHit

["Mik Kersten" <beatmik@xxxxxxx>]

I don't think that creating keys for repository tasks is worth maintaining
the extra map.  Tasks have an identity that's well-defined by their
repository and by their ID in that repository.  In other words, we layer
over the ID that's used and maintained by the DB (i.e. the repository), and
we qualify it with the URL of the repository.  URLs tend to be robust, but
it's also easy for us to 'refactor' them on change since we only have one
thing to change.  Also, there are numerous benefits to using a String and
path-based identifier for our task proxies, our use of which is very similar
to the other instances and rationalizations for the "virtual proxy" pattern
used throughout Eclipse.  For example, if either part of the path (URL or
ID) fails to resolve we can try to match it, as we do when resolving commit
comments.

Mik

> -----Original Message-----
> From: mylar-dev-bounces@xxxxxxxxxxx [mailto:mylar-dev-bounces@xxxxxxxxxxx]
> On Behalf Of Eugene Kuleshov
> Sent: Friday, November 03, 2006 7:27 PM
> To: Mylar developer discussions
> Subject: Re: [mylar-dev] changes to AbstractQueryHit
> 
> Mik Kersten wrote:
> > Those ancient cripples are still contributing though...  They ensure
> that
> > the repository URL and in general whole identity of a task are defined
> by
> > the repository URL and ID.  This helps provide a robust mapping between
> the
> > IDs that appear in the task activity context, and it means that there is
> > only one thing to rename when the user renames a repository (i.e.
> refactors
> > its URL).  That said we definitely need to improve this API because it's
> > awkward always calling those static methods on AbstractRepositoryTask.
> >
>   That sounds really really wrong. I think both repositories and tasks
> should use some kind generated ids, so you won't have to rename anything
> and just use those as a cross references.
> 
>   Ask any DBA about this, they will tell you how to link two tables
> together and also fhy using business fields for the foreign key is
> really bad idea... :-)