>And then in the future users see a setting to switch to MySQL and think >'hey I heard that - this is the famous open source DB, let's use this' >and fail because: >- Logitechs QA is not as dedicated to MySQL compared to SQLLite >- They still have they virus scanners on causing trouble (even me is >getting a support request once a month, which in the end boils down to >virus scanner issues). > That's fine - they'd have an option, and if it didn't work, could switch back.
>So again unhappy customers for no reason. > Or happy customers because they have an option, and it may work better. >Keeping MySQL only has drawbacks and very rare pros: > I see no drawbacks for end-users, as they have an option. I see little drawback for provision of the DB engine, as it is already provided. If it fails to work in future, maybe third-party devs would fix and provide patches. It doesn't even have to be a simple switch in the GUI - maybe only power users that know what they are doing might configure it in prefs file directly. I've never used the built-in MySQL instance, I've always used my own by manually configuring the prefs file. There has been little analysis to compare performance. Will SQLite actually work well enough for everyone on every platform? To totally remove MySQL, switch to SQLite and release only to find major issues with SQLite would be annoying. I'm fairy happy to switch to SQLite, if there's evidence that it provides equivalent/better functionality/performance to my current experience, and not just because it has to be used for embedded SBS for Touch for Logitech to sell Touch's, and not detrimental to full SBS. SQLite is certainly not as good for development (poor dev tools, in comparison), and performance is vastly reduced if you don't lock the DB file to allow DB probing. The SQL engine itself has lots of very iffy things, SQL query language isn't as good and is missing loads of things. Not sure about character encoding issues - we could end up with even more bugs/things that won't be fixed because DB doesn't support blah blah. eg. "SQLite does not enforce the length of a VARCHAR. You can declare a VARCHAR(10) and SQLite will be happy to let you put 500 characters in it. And it will keep all 500 characters intact - it never truncates." Sometimes you want a DB engine to fail/constrain data size. It pushes problems further into app code, so more checking may be required to protect app. "Case-insensitive matching of Unicode characters does not work." >(-) you get all kind of trouble with virus-scanners again > I don't see this issue really. Anything that writes/locks files can have trouble with virus scanners. Why should SQLite be any safer to MySQL? Phil _______________________________________________ beta mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/beta
