Why are multiple revisions allowed in submissions

[Kevin Dalley]

The function db_read allows multiple revision lines (# Revision: n).
DBFORMAT seems to allow only one revision string.

Being nice to users is fine, but I favor being strict with the client
programs and making the follow the defined format. I believe that the
responses to a "cddb read" request removes the extra lines, if they
have not been removed during the submission process. Thus, clients
don't have to know how to handle non-standard files.

I did find two files in the database with doubled revision lines.
Both of them had one blank revision in addition to one numbered
revision.

Are there any known clients which submit files with multiple revision
lines?

[Joerg Hevers]

Hello,

Post by Kevin Dalley
The function db_read allows multiple revision lines (# Revision: n).
DBFORMAT seems to allow only one revision string.
Being nice to users is fine, but I favor being strict with the client
programs and making the follow the defined format. I believe that the
responses to a "cddb read" request removes the extra lines, if they
have not been removed during the submission process. Thus, clients
don't have to know how to handle non-standard files.

For a submission with multiple revision lines, only the last line is
taken into account and the file written to the database will only
contain one revision line.
The only case in which this doesn't work is for a "# Revision: " line
with no Revision number following - probably because it is not
recognized as a revision comment, but treated as a normal, meaningless
comment line.

Post by Kevin Dalley
I did find two files in the database with doubled revision lines.
Both of them had one blank revision in addition to one numbered
revision.

Can you give genre/discid, so I can fix them?

Post by Kevin Dalley
Are there any known clients which submit files with multiple revision
lines?

No, I don't know any - If I knew such clients, I would have notified
the authors about the bug.

Best regards, Joerg

[Kevin Dalley]

Post by Joerg Hevers
For a submission with multiple revision lines, only the last line is
taken into account and the file written to the database will only
contain one revision line.
The only case in which this doesn't work is for a "# Revision: " line
with no Revision number following - probably because it is not
recognized as a revision comment, but treated as a normal, meaningless
comment line.

Post by Kevin Dalley
I did find two files in the database with doubled revision lines.
Both of them had one blank revision in addition to one numbered
revision.

Can you give genre/discid, so I can fix them?

Here are the bad files:

rock/e40f1f10
classical/430f5a15

Post by Joerg Hevers

Post by Kevin Dalley
Are there any known clients which submit files with multiple revision
lines?

No, I don't know any - If I knew such clients, I would have notified
the authors about the bug.

Why not refuse to accept submissions from a client which gives two
revisions? That would strongly encourage clients to behave, and make
cddbd's behavior more predictable.

[Andy Key]

Post by Kevin Dalley

Post by Joerg Hevers

Post by Kevin Dalley
Are there any known clients which submit files with multiple revision
lines?

No, I don't know any - If I knew such clients, I would have notified
the authors about the bug.

Why not refuse to accept submissions from a client which gives two
revisions? That would strongly encourage clients to behave, and make
cddbd's behavior more predictable.

[This is not a flame]

Wouldn't it be better to fix the flawed server-side logic instead (storing
mandatory information in "comment" lines, update vs. insert semantics, get
rid of genre as part of the primary key for CD's, no multiple entries for
same CDDBID hash/genre combination, etc...)? Unfortunately, it was designed
wrong from the very beginning (or probably just grew from a scetch on a
napkin), and that makes it difficult to change once the critical mass of
users has been reached.

It would be nice if there was a good way to migrate away from the current DB
format to an RDBMS, use XML for encoding submissions, updates and queries,
which would allow for automatic validation and parsing without every single
client having to reinvent the wheel. XML has another nice side-effect of
making it easy to use various character encodings.

-Andy

_________________________________________________________________
Chatujte bezpecne s lidmi, ktere si umistite na seznam svych pratel -
stahujte MSN Messenger 6.1! http://www.msn.cz/procmessenger

[Kevin Dalley]

Change a little at a time.

I do have a RDBMS version of the server almost ready for testing.
Give me another few days to a week, at least I said this last week. I
believe that RDBMS will allow for XML clients, without disturbing the
old clients.

freedb has been changing and improving over time. If freedb weren't
this useful, people wouldn't complain about its shortcomings, it
would just be dropped.

Post by Andy Key
Wouldn't it be better to fix the flawed server-side logic instead
(storing mandatory information in "comment" lines, update vs. insert
semantics, get rid of genre as part of the primary key for CD's, no
multiple entries for same CDDBID hash/genre combination, etc...)?
Unfortunately, it was designed wrong from the very beginning (or
probably just grew from a scetch on a napkin), and that makes it
difficult to change once the critical mass of users has been reached.
It would be nice if there was a good way to migrate away from the
current DB format to an RDBMS, use XML for encoding submissions,
updates and queries, which would allow for automatic validation and
parsing without every single client having to reinvent the wheel. XML
has another nice side-effect of making it easy to use various
character encodings.