-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Max once thought about using SQLite as backend. He even was clear that,
if done right, there shouldnt be ANY regression in speed. Not sure what
the plans are for now. I guess there are more important things :)
Regards, Rasi
Jonny wrote:
I know that people have asked why MPD doesn't use an SQL database in
the past, and I know also that the reason has been performance.
I'm not disputing this, and I don't want to start any kind of flame
war, but aside from performance the use of SQL does allow for more
features (or for making such features much easier to implement):
1 - Smart / dynamic playlists via complex SQL queries
2 - Easy maintenance of the database by external utilities using standard SQL
3 - Housing database on different machine from MPD (likely to cause a
performance hit, I know)
4 - MPD clustering (an unlikely use case for most of MPDs users, I admit)
For me personally, the second option is actually a biggie - currently
one cannot manage the MPD database at any kind of granular level.
Asking mpd to do an 'update' on its music directory has never
completed for me - on an NFS-mounted 100GB+ music library. When I add
things to the database I add things by name (e.g. mpc update
Artist), but if I move files around or want to remove music from
MPD's library, there doesn't seem to be any command to do that. I can
only do 'update' on parts of the library and hope that MPD picks up
that files are deleted / changed. I notice that MPD will also only
rescan files if their modification date has changed; there seems to be
no way to force MPD to re-scan a file/directory regardless of its
modification time (which is useful in some situations).
If these commands/features were added, I'd probably have less of a
need for SQL personally, although the first idea above would be nice.
I should also emphasise that in my view this doesn't have to be an
all-or-nothing decision. Why not use a database plugin, and default to
the internal MPD database, but allow the option of using
SQLite/MySQL/etc? Wouldn't this satisfy both those who don't care/need
the performance and those who want the flexibility of SQL?
Kind regards,
Jonny
--
___
Musicpd-dev-team mailing list
Musicpd-dev-team@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkpIl9wACgkQswz/d6k9dsXBoACfbMpRUsSkiHQPfjpTS4i4uck+
mGAAnis2Vlx/QMUs9qTgYXPT3j3T0HIX
=FNlU
-END PGP SIGNATURE-
--
___
Musicpd-dev-team mailing list
Musicpd-dev-team@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
