RE: Status of PostgreSQL port of cddbd

"Jacob Alifrangis" <[email protected]> Mon, 15 Dec 2003 00:23:44 -0800
Newsgroups gmane.comp.audio.freedb.devel
Message-ID <[email protected]>
In other news, I have begun work on a MS-SQL Version of cddbd.

It is a work in progress, but In several ways, it is much faster than cddbd
for unix.
IT supports regular expression matching and direct lookup. I am still trying
to decide how best to license the server since it uses NO code from
freedb.org, it only has an import function for the existing freedb data.

It supports star or descendant replication methods for a system wide
load-balancing update scheme. Meaning that all updates are processed locally
then uploaded to a master server where they are validated and redistributed
weekly, And automatically.

The software is written in c# and vb.net and will, when ready compile on
mono.

Let me know, since this is really a whole new animal, what you think. This
might wind up being a competing product for the freedb system, it might not
be.

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf
Of Kevin Dalley
Sent: Monday, December 15, 2003 12:16 AM
To: [email protected]
Subject: [fdb-dev] Status of PostgreSQL port of cddbd

I have made a lot of progress with the PostgreSQL version of cddbd.
Most of the code is somewhat tested.  Is there a cddbd test suite to
verify functionality?  I suspect that I have misinterpreted some
items, and just screwed up others.  The database has separate columns
for artist and title, allowing for multiple artists for each track.

I have quite a few questions which I will send in separate email.

Now, some general information.  The disc space required is similar to
that used by the standard files.  The exact numbers depend upon what
features are required, and how many indexes are built.  The number of
files has gone down, of course.  reiserfs is probably not necessary.

In many cases, I use the same infrastructure and functions as the
current cddbd.  history files are still in text, though they probably
should be moved to the database some day.  Posts still use plain old
text files.  I think this is reasonable.  The fuzzy index is stored
the same way, but it is generated for the database.

The PostgreSQL server can do *almost* all of the needed functions,
including updates, transmits, validating entries, etc.  I haven't
strongly tested the merging code.  I suspect there are a few
outstanding bugs.

I'm still missing cddbd_do_catchup, the "-T option to cddbd.  This
option resets the transmission history to a known time.  In order for
this option to work, I have to add time stamps for each CD entry.  This is
doable, but I had other things to do first.

I'm missing cddbd_match, which looks for files which should be linked.

Most other functionality should be there; not all of the functionality
has been tested.  I usually find bugs during testing.

I would like to have some people test the software in the next few
weeks, after I perform some more cleanup.  Is anyone interested in
testing the software?

-- 
Kevin Dalley
[email protected]

_______________________________________________
fdb-dev mailing list
[email protected]
http://dtype.org/mailman/listinfo/fdb-dev