Re: [UDD] Role of different upstream status tables (upstream versus dehs)
On 27/05/15 at 16:33 +0200, Andreas Tille wrote:
> Hi Lucas,
>
> On Wed, May 27, 2015 at 08:51:30AM +0200, Lucas Nussbaum wrote:
> > > If somebody could explain the role of these competing tables I could
> > > decide whether adapting the Blends code or filing a bug report would
> > > be the appropriate course of actions.
> >
> > The dehs table was trying to mirror the data provided by DEHS.
> > Unfortunately, DEHS died a long time ago, so the 'upstream' gatherer
> > (and table) were created.
> >
> > I recommend that you switch to using 'upstream' instead of 'dehs'.
>
> OK, fine for me. BTW, I noticed some implementation detail:
>
> -- DEHS
> CREATE TYPE dehs_status AS ENUM('error', 'uptodate', 'outdated', 'newer-in-debian');
> CREATE TABLE dehs (
> source TEXT NOT NULL,
> unstable_version debversion,
> unstable_upstream text,
> unstable_parsed_version text,
> unstable_status dehs_status,
> unstable_last_uptodate timestamp,
> experimental_version debversion,
> experimental_upstream text,
> experimental_parsed_version text,
> experimental_status dehs_status,
> experimental_last_uptodate timestamp,
> PRIMARY KEY (source)
> );
> GRANT SELECT ON dehs TO PUBLIC;
>
> ...
>
> CREATE TABLE upstream (
> source text,
> version debversion,
> distribution text,
> release text,
> component text,
> watch_file text,
> signing_key_pgp text,
> signing_key_asc text,
> debian_uversion text,
> debian_mangled_uversion text,
> upstream_version text,
> upstream_url text,
> errors text,
> warnings text,
> status text,
> last_check timestamp,
> primary key (source, version, distribution, release, component)
> );
>
> I'd consider the implementation of status as ENUM more performant than
> a plain text. Am I missing something?
status is returned by uscan. I did not want to write in stone the list
of possible statuses returned by uscan.
Lucas
Reply to: