Philip Meyer;566680 Wrote:
>
> MySQL works great for me - I see no point in switching to SQLite which
> may not work as well.
>
This is simple.
SQLite is the ONLY working solution on the built-in server on the
Touch, so it has to be supported.
So the option is to either only support SQLite and focus on making that
really good or to spend time trying to support several database
backends. There is no way Logitech can select to only support MySQL
since that won't work on the built-in server of the Touch. If we didn't
have to consider the built-in server on the Touch, the decision would be
a lot harder.
The problem is that if several database backends are going to be
supported, it's going to cost development time, QA time and support
staff time. Of these the development time is probably least number of
extra hours, the big problem is QA and support. If Logitech only
supports a single database in QA and support, the other one is going to
stop working, it's just a matter of time. The reason is that QA and
support prioritizes bug reports and we already know that bugs that are
a problem for QA and support are prioritized higher than bugs that are
only a problem for advanced users.
Based on what Andy says, it sounds like the only reason they even
consider keep MySQL is for some of the advanced community members that
are used to it.
Now, the big question is: Is it more important to you to keep MySQL
than getting some new features than enhances your music
discovery/listening experience ?
If the answer to this question is that the music related stuff is more
important I feel that we should just drop MySQL support and instead put
the focus on making SQLite really good and use any additional time left
for music related features.
Philip Meyer;566680 Wrote:
>
> I don't see what the issue is with supporting MySQL and SQLite. Is it
> the difference in queries, or the support for creating the DB schema,
> or supporting the hosting environment?
>
I don't think queries are the big problem, queries are a little bit
bigger issue today as we now use SQL directly in some places to
optimize performance instead of object based DBIx::Class generated SQL.
However, the queries are pretty much identical for the simple queries
that's used in most places in SBS. I believe the queries are a lot
bigger issue in some of my plugins than for Logitech, the reason is
that I tend to use more advanced database functions.
Andy will have to confirm this but I believe the big difference is
related to how the database is handled during scanning, for example
creating/dropping database and reconnecting it with the persistent part
of the database (ratings, play counts and other statistics) after the
scanning has been performed.
An important point to also remember is that supporting two database
backends doesn't only affect Logitech, it will also affect third party
developers like myself who develop database intensive plugins. Logitech
at least have about 4-5 full developers that can do the work and a QA
team of unknown size. I "only" have access to my own spare time to do
both development and QA and support of my plugins, so if I need to
split my focus to do development, QA and support for both SQLite and
MySQL it means that users will get less features. The alternative would
be that I decide to drop support for one database backend completely.
Since I do care about the end users, it would probably mean that I
would drop support for MySQL since most users are going to use the
database that's selected by default. The situation for me is the same
as for Logitech, the big problem isn't to develop for two databases,
the big problem is to do QA and support for two databases. So even
though my plugins currently works better with MySQL it will cost me QA
and support time to keep MySQL working.
So on top of the question I asked earlier in the post, you also have to
question yourself if you want to keep using MySQL if neither TrackStat,
Custom Browse nor SQL Playlist is supported under MySQL ?
ANDY (OR ANYONE ELSE AT LOGITECH):
Assuming you are sure that you can get good performance with SQLite in
libraries of 50-100 000 tracks this should be an easy decision,
especially since it sounds like the QA and support teams has already
taken or will take the decision to drop MySQL. You will get some
complaints here in the forum if you drop MySQL but you can easily
defend yourself by saying that with the smaller team you have to
prioritize and you like to focus any extra time on music related
features.
IMHO, the ONLY reason that possibly can justify keeping MySQL is if we
believe that it will be hard/impossible to get good performance in
larger libraries with SQLite. However, to make this justify keeping
both databases the difference have to be big, if we are talking about
less than 30% difference in performance it's not worth the time when
you consider that probably less than 5% of the users have libraries
with more than 50000 tracks. If we are afraid that SQLite will make SBS
unusable for users with more than 50000 tracks the situation is
different, but this isn't really the case, is it ?
So even though I personally like MySQL better than SQLite, I'm not
prepared to sacrifice music related features to have more technical
options when configuring the system. All this focus on technical stuff
is silly, most people have their Squeezeboxes to play music, so that
should be the main focus.
So, let's put the focus on the music related stuff and select the path
that leads to most music related features.
--
erland
Erland Isaksson ('My homepage' (http://erland.isaksson.info))
(Developer of 'many plugins/applets'
(http://wiki.slimdevices.com/index.php/User:Erland). If my answer
helped you and you like to encourage future presence on this forum
and/or third party plugin/applet development, 'donations are always
appreciated' (http://erland.isaksson.info/donate))
------------------------------------------------------------------------
erland's Profile: http://forums.slimdevices.com/member.php?userid=3124
View this thread: http://forums.slimdevices.com/showthread.php?t=80914
_______________________________________________
beta mailing list
[email protected]
http://lists.slimdevices.com/mailman/listinfo/beta
