Re: [UDD] Role of different upstream status tables (upstream versus dehs)

[Andreas Tille <andreas@an3as.eu>]

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?

> I've just emptied the dehs table to make it clearer that it should not
> be used.

May be a bit abrupt action but in principle fine. :-)

Kind regards

       Andreas. 

-- 
http://fam-tille.de