Re: [GSoC] Prospective packages importer

Hi,

On Sat, Aug 22, 2015 at 8:19 PM, Andreas Tille <andreas@an3as.eu> wrote:
>
> > I have studied the details of prospective packages in tasks pages. I think
> > it is better to add prospective packages which are not in udd yet to the
> > already existing "blends_prospectivepackages" table than creating a
> > separate table for them. Logically, all these are prospective packages and
> > all such packages should be kept in a single table. Does this seem good?
>
> Well, I think both possibilities (use one table for all or two tables)
> are technically equal from an SQL point of view. From an UDD point of
> view it works usually in a way "truncate the table include data from
> scratch". In this aspect a separate table would fit the philosophy a
> bit more *if* (and only if) you decide for a separate script for the
> import. If you just want to enhance the existing prospective package
> importer I fully agree with you.
>

Hmm. Ok. So, a separate script seems like a better idea for now. The new table can be "blends_unknown_packages". Is the name alright ?

> > To enhance blends_prospectivepackages - the following extra columns need to
> > be added:
> >
> > -> pkg-url
> > -> remark
> > -> language
> > -> note
> > -> enhances
> > -> X-category
> > -> X-Importance
>
> The fields with X- are basically comments for the task file editor so
> you can ignore this one. Do we have "Note" fields? Without checking
> the docs I think this is undocumented and should be turned to either
> "Remark" or X-Note (=be ignored).
>
Ok. I'll not add X-category, X-importance. The Note fields is present.

eg 1)

Depends: amoscmp
Homepage: http://amos.sourceforge.net/docs/pipeline/AMOScmp.html
License: Artistic
Pkg-Description: comparative genome assembly package
.
.
.
modular open-source framework for assembly development.
Note: Genome assembly and large-scale genome alignment (http://www.cbcb.umd.edu/software/)

eg 2)

Depends: splitstree
Homepage: http://www-ab.informatik.uni-tuebingen.de/software/splitstree3/welcome.html
License: to be clarified
.
.
.
Note: There is a new version 4.0 written from scratch at
http://www.splitstree.org/ which requires a license key - so this is
probably non-free. Version 3.2 which is linked above has some
downloadable source code without any license or copyright statement -
so it has to be clarified whether we are able to distribute this code
or not.
Remark: This package ships with BioLinux http://envgen.nox.ac.uk/biolinux.html

There is a note and also a remark.

The Note is not displayed in the current tasks files. It is probably treated as X-note. So, should I ignore this ?

> > After adding the above column, the information of prospective packages
> > already in udd can be enhanced and new prospective packages can be added to
> > the same table.
>
> Fine.
>

Since, I plan on using a separate table for inserting these prospective packages, we don't need to alter the current blends_prospectivepackages table. It seems information like - enhances, language etc. do not need to be added for the existing prospective packages. We may not need to add extra columns to the table.

> BTW, an idea came into my mind that we have even Remarks for *existing*
> packages. These would get lost if we only have remarks for the
> prospective packages. So we need an extra table
>
> package | remark
>
> Does this sound sensible to you?
>

Yes. It is a really good idea. A separate table say "package_remarks" will cover the remarks for all packages (not just prospective ones).

> > That said, I feel most of these columns will remain empty as the
> > information above is not specified for all prospective packages. Will this
> > be a problem ?
>
> Definitely no problem - that's natural.
>
> > Do you think all this information will be made available for
> > all packages in the long run ?
>
> I do not understand this question.
>

What I meant was, most of the columns will be empty for now. Say, most packages do not have information (like 'language') now. Will the 'language' for all packages in the table be made available some time in future ? I hope I am clear in my question now.

> > Also, how do I go about altering the table ? Should I make changes to
> > sql/upgrade.sql ?
>
> Create a separate sql script and I'll merge.
>

So, the sql script will include:

Creating two new tables - blends_unknown_packages and package_remarks.

Is there anything else I am missing out ?

--
Regards,
Akshita Jha