Re: [Pan-devel] Re: Code & DB update notice

[K. Haley]

Michael A Chase wrote:

> >    username          (string NOT NULL)
> >    password          (string NOT NULL)
>
> Not all servers require username and password so these should probably
> allow NULL.
If the data is stored in the DB as a NULL or an empty string, it will be
read and stored in pan as an empty string.  While I can alter the code
to write a NULL when the string is empty, I don't see any benifit at
this time.  The same is true for the group description.

> >    filter_name       (string NOT NULL)
> >    filter_show       (uint32 NOT NULL)
> >    filter_bits       (uint32 NOT NULL)
>
> I don't know what these are for.
I believe this deals with which articles are shown ie. read, cached, etc.

> > GROUP_SERVER
> > Pair each group with 1 or more server, and each server with 1 or more group.
> > This way "get new headers" will know which servers need to be hit.
> > Also keep track of min and max article numbers.
> >
> >
> >    article_min       (integer=0 NOT NULL)
> >    article_max       (integer=0 NOT NULL)
>
> I think newsrc files have disjoint lists of the articles downloaded.  Is
> there any place to store lists of article number ranges?
Those values are provided by the server.  They indicate the range of
articles in the group, any articles outside that range should be removed
from the g_s_a table.  If you want to know which articles are already in
the db just use
SELECT uid FROM g_s_a WHERE group_server_id=? ORDER BY uid;

> > VSERVERS
> > Name of each vserver except the default server.
>
> Why not the default server too?  The default might change over time.
I really should update that text.  The default servers are "All Groups",
Subscribed, "New Groups", and Folders.  These are special in that they
should always exist and they can be easily populated from the db.  There
is also a localization issue since those strings are localized in pan.
Not to mention that someone could alter the db directly.

> > File: pan_article.sqlite3
> >
> > REFS
> >  ! article_id        (int NOT NULL) ARTICLE:id
> >    reference         (BLOB NOT NULL) 16 byte MD5 hash of 1 reference
> >  * id                (int primary key)
>
> Where is the reference itself kept?
Currently the References header is thrown away after refs has been
populated.  If it's decided to keep it then it can be placed in headers,
that's what it's their for.

> > ARTICLE_HEADER
> >    aid               (int NOT NULL) ARTICLE:id
> >  ! hid               (int NOT NULL) HEADERS:id
> >  * id                (integer primary key)
>
> Would it be useful to preserver the order of headers in an article?
> Normalizing the display order has a lot to say for itself too.
The headers & article_header tables are not used for display.  They are
for keeping extra headers such as Refernces & XRefs.  They may also be
used for scoring at some point.  There is nothing currently in my code
to populate these tables.

signature.asc
Description: OpenPGP digital signature