>b/c i have had many problems not with AV, but windows defender, that i
>believe cost me two raptor HDs.
??? Are you saying that because SBS was using MySQL, it cost you two raptor
HD's, and switching to SQLite will obviously prevent that from ever happening
again?
Or in reality perhaps Windows Defender was the problem, and thus removing that
would prevent the problem.
>anyway, erland says his plugins (which i don't use, but i will test the
>one this weekend!) will work on sqlite.
>
Might not work as well - who knows unless they are completely regression tested
(and with comparative stats to see whether there's an improvement or
degradation in performance).
>so my question is what
>indispensible plugin or feature do we lose if mysql is no longer
>supported?
>
Who knows, unless everything is retested. And where several of the third-party
plugin devs have departed or no longer maintaining their plugins, how will they
be upgraded?
>frankly, i doubt there is any.
Quite possibly most will work. But also likely that a few will not without
(minor) changes.
>whatever niche cases there are, really don't hold any water. give me a
>showstopping reason as to why mysql must be maintained, or get over it.
In the old days, when there was SlimServer, it used its own data structure, not
a DB engine.
Then it was changed to use SQLite.
This had loads of problems, and thus the engine was switched to use MySQL.
Support for SQLite was dropped instead of maintaining it in case it was ever
switched back. This has worked well; it is a known and trusted entity. It
will work better with large libraries (but at what library size is unknown).
There are less locking issues; it is a better DB engine with better tools.
There was much joy with devs when SQLite was dropped and MySQL was used.
It just seems strange to me to totally remove support for the engine, seeing
that:
1) history has shown that this product has changed it's mind over DB engine
several times already.
2) MySQL worked fine, and really should be simple to maintain:
a) DB Engine comms is a one-off job, already done (but broken). Should
have added support for SQLite, rather than change support. It would be a bit
like changing WixXP support for Vista, instead of adding Vista support.
b) SQL statements have some minor differences (MySQL generally has more
functionality - I think closer support of ANSI SQL, and better extended
functions support). In most cases ANSI-SQL will work with both engines.
Of course, the only real reason why DB engine is changing again is to support
Tiny SBS, a product that has much reduced functionality, otherwise I'm pretty
sure full SBS wouldn't be changing. That driving decision is going to creep in
all the time, with full SBS functionality being reduced to meet requirements of
TinySBS.
At the same time, I agree - if SQLite were indeed a better solution, there'd be
no reason to support MySQL. However, SQLite isn't a better solution (for full
SBS). I'm thinking that actually, full SBS isn't so much on the agenda these
days, just Tiny SBS as that is a selling point for newer hardware players.
Maybe OS support will be dropped next, because it only needs to run on Linux to
run on Touch (I think not, but maybe more development for Tiny SBS and less of
a driver for full SBS, and Tiny SBS bugs/enhancements may take precidence over
support for lesser used OS's in full SBS).
No doubt that some time in the future I will switch to 7.6 with SQLite. But at
the moment, 7.6/SQLite doesn't seem to run too well for me. It doesn't seem to
improve performance, and some plugins don't work. There's little incentive
(killer features in 7.6) - yet!
Phil
_______________________________________________
beta mailing list
[email protected]
http://lists.slimdevices.com/mailman/listinfo/beta
