ExtensionList page should list most recent extension about slicerappstore HOT 11 CLOSED

Looking back at this issue, I realized there are not additional commit in SkullStripper repository, it probably means that the code associated with commit f28307b874 has some issue.

@finetjul Could you confirm that you locally created a new commit before uploading the SkullStripper extension including the icon.

• If you did, it means the present issue applies.
• If you didn't create a commit, it means commit f28307b874 will have to be revised and new issue created.

from slicerappstore.

// Only filter by a subset of the parameters
$results = $this->get(array(
'os' => $params['os'],
'arch' => $params['arch'],
'repository_type' => $params['repository_type'],
'revision' => $params['revision'],
'slicer_revision' => $params['slicer_revision'],
'packagetype' => $params['packagetype'],
'codebase' => $params['codebase'],
'productname' => $params['productname']));

Those are the parameters we match on. If we find a matching extension, we upload into it. The code appears to be working on the server as several log messages indicate that we have new revisions uploaded into existing extension items. Note that this won't fix items uploaded prior to the commit, only on packages uploaded afterwards. Also, if multiple matching items already exist, we update the first one and ignore the rest.

from slicerappstore.

Thanks for clarifying

To address this issue, we should probably update the function get from the extension model so that it returns only the most recent extension based on 'date_update'. Not sure if we should add an other function to the web API / controller or add a parameter to the existing one.keep the web API

Say differently, if have the following extensions:

name | slicer_revision | extension_revision | date_update
A        |  100                  |       Ad43                  |  15/03 
B        |  100                  |       V5Hj                  |  15/03
A        |  100                  |       G57J                  |  16/03 

Only the second and third extension should be returned.

Some possible approach:
http://stackoverflow.com/questions/537223/mysql-control-which-row-is-returned-by-a-group-by
http://kristiannielsen.livejournal.com/6745.html
http://www.xaprb.com/blog/2006/12/07/how-to-select-the-firstleastmax-row-per-group-in-sql/

from slicerappstore.

You mean we should never return multiple extensions with the same name? I don't think that is an ideal solution, it seems to mask the existence of data in the system. If there is an extension we never want to display, shouldn't we just remove it from Midas altogether?

from slicerappstore.

I don't think we should remove these extensions.

Currently, these extensions won't be displayed, but later on it should be possible for a user to install a previous version of a given extension (assuming the slicer revision match)

from slicerappstore.

Ok, I can implement your solution then.

from slicerappstore.

J2 and I just came up with an elegant solution for this that doesn't involve very complex database queries and filtering.

We remove 'revision' as one of the key parameters for an extension, and then so that we won't ever lose that revision data, we set the revision field as the text on the midas item revision to maintain the correspondence of midas revision with the extension repository tag.

from slicerappstore.

Currently, the revision as in "extension revision" is not part of the key or query parameter to obtain the list of extension matching a given revision of Slicer.

That said, I am not sure to understand how it would help us doing the query where we went the most recent extension per slicer revision.

On the other hand, if we add a field named last_extension to the slicerpackage_extension table, we could eventually update that field each time an extension is uploaded.

from slicerappstore.

Btw, we realized that the duplicate entry comes from the extension package name being different. Indeed, it contains the date when the extension has been cut.
In this case (extension for 4.1), the package name shouldn't contain a date in its name(optionally a "Slicer-4.1" suffix)

from slicerappstore.

In that specific case, where you created a package with local change at a different date, more generally the problem will occur each time a different revision of an extension is build and packaged against a given revision of Slicer.

For example:

• 19895-linux-amd64-SkullStripper-git4a5b7e0b806c9cb17cf4ea53365dc81a3555c9e8-2012-04-14.tar.gz
• 19895-linux-amd64-SkullStripper-gitdff2d021acc6e9f283abc0db288c108c167551f3-2012-04-14.tar.gz

That's why I advise to implement the general solution reported above where the grouping could be done on the following fields:

• item.date_update
• slicerpackages_extension.os
• slicerpackages_extension.arch
• slicerpackages_extension.repository_url

The corresponding midas code could be derived from this query:

select e1.item_id, e1.os, e1.arch, e1.repository_url, e1.revision, e1.submissiontype, e1.packagetype, e1.slicer_revision, 
e1.release, e1.icon_url, e1.productname, e1.codebase, e1.development_status, e1.category, 
e1.description, e1.enabled, e1.homepage, e1.repository_type, e1.screenshots, e1.contributors 
FROM item i1, slicerpackages_extension e1,
(
  SELECT e2.slicer_revision, e2.os, e2.arch, e2.repository_url,
         max(i2.date_update) AS date_update 
  FROM item i2, slicerpackages_extension e2 
  WHERE e2.item_id = i2.item_id 
  GROUP BY e2.slicer_revision, e2.os, e2.arch, e2.repository_url
) grouped_e
WHERE i1.item_id = e1.item_id 
AND i1.date_update = grouped_e.date_update 
AND e1.slicer_revision = grouped_e.slicer_revision 
AND e1.os = grouped_e.os 
AND e1.arch = grouped_e.arch 
AND e1.repository_url = grouped_e.repository_url

Regarding the special suffix matching the revision of Slicer instead of the date. I agree that it could be nice but it wouldn't solve our problem.

Ps: Note that commit dff2d021acc6e9f283abc0db288c108c167551f3 do not exist and was locally made for the purpose of the example.

from slicerappstore.

I believe this has been resolved so I am closing it.

from slicerappstore.