On 2009/06/29 12:27, Jonny <jonnyt...@gmail.com> 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
Write a perl script which imports the MPD database file into a SQL table. Should be no more than 20 lines of code. > 2 - Easy maintenance of the database by external utilities using > standard SQL What kind of maintenance do you mean? > 3 - Housing database on different machine from MPD (likely to cause a > performance hit, I know) For what reason, except for "because you can"? If you have your music on NFS, you can point the database file to NFS, too. That's a lot faster than SQL. Prove me wrong. > 4 - MPD clustering (an unlikely use case for most of MPDs users, I > admit) What is the advantage over simply copying one single database file over to the other MPD server? > 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. What was the problem? How will a SQL database improve this? > 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). Implementing that "database rebuild" command is a very tiny task compared to your SQL database feature. > 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? Making stuff pluggable is a good thing. In this case however, I'm not convinced. There are so many other approaches to your problem which are less complex than your solution. If you do it right, and if you can show real advantages or good benchmark results, we can talk about merging your code. Max ------------------------------------------------------------------------------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/blackberry _______________________________________________ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
