Community
Participate
Working Groups
AbstractQueryHit.id should be a String because there are many cases when task identifier can't re represented as integer value. This is actually needed for the web repository provider.
Created attachment 45686 [details] mylar/context/zip Context for this issue. PS: note 39 opened editors that isn't look right to me
Created attachment 45687 [details] patch changing type of id to String
Created attachment 45794 [details] patch changing type of id to String (updated)
I reviewed the patch and can not apply as is because a single malformed handle would cause Mylar to blow up in all sorts of wierd ways. First, AbstractRepositoryTask.getTaskId() relies on the '-' delimiter denoting the start of the ID, so an ID with a dash in it would break handles. Also, if any of trhe numerous Interger.parseInt() calls failed there would be a flurry of exceptions thrown on the numerous refreshes. And we really need a test for such a change. I'm going to take a stab at making this change and report back.
Damn it! I knew you'd say that. Well, I guess it would require to resolve Bug 149624 first...
Not necessarily. What I'm in the process of doing now is making ids with a '-' in them illegal. Down the road if we want to remove that restriction we will need to migrate all the handles of contexts to a new format. The minimal information needed to define the identity of a task is a repository URL and an ID for that task so the current handle approach makes sense, but it will now be better hidden by AbstractRepositoryTask.
(In reply to comment #6) > Not necessarily. What I'm in the process of doing now is making ids with a '-' > in them illegal. Is your intention to brak Jira? E.g. MNGECLIPSE-150: Repository Search results in error http://jira.codehaus.org/browse/MNGECLIPSE-150 > Down the road if we want to remove that restriction we will > need to migrate all the handles of contexts to a new format. The minimal > information needed to define the identity of a task is a repository URL and an > ID for that task so the current handle approach makes sense, but it will now be > better hidden by AbstractRepositoryTask. I'd drop that relation between id and repository URL. SourceForge is not using unique id's (each project has its own namespace) and probably some others too. So, I think the best is to save task url and repository url independently and keep separate id as well to avoid recovering it from the task url.
MNGECLIPSE-150 is the key of that issue, not the ID. JIRA provides unique int IDs for every issue, and if an issue moves between projects it maintains IDs but gets two separate keys. Now that we will have String IDs they will be able to contain namespace information, which is in part why I gave this change priority (for you and others). However, it will be recommended that repository connector implementations use the most basic and stable form of ID in order to preserve the identity of tasks.
(In reply to comment #8) > MNGECLIPSE-150 is the key of that issue, not the ID. JIRA provides unique int > IDs for every issue, and if an issue moves between projects it maintains IDs > but gets two separate keys. Well, if I fetch this task using web connector it will be id.
Right, and that ID will break if that task moves. That's a fine limitation for the generic web connector, but not for the proper Jira Connector.
Can you maybe use a '?' as a separator?
We can consider changing the separator once there is a compelling driver to do that, and encoding the other dashes turns out not to be a good option. However, that would involve a major migration of all the data in the .mylar folder. As expected this task turned out to be quite involved, including all that was in your patch and then some (e.g. task editors). I think I'm close to finishing now.
Done.
Created attachment 45810 [details] mylar/context/zip
Thanks Mik. I resubmitted patch for Bug 145123
Glad that we got it in there. For changes that tangled it's probably best to just specify how you want it done since there are bound to be non obvious and untested problems. For everything else patches are best ;)
