tamanaco;433625 Wrote: > The pain of having to re-rate the tracks that I have rated and having to > re-create new browsing shortcuts that I have already created with > MySQL-"dependent plugins". > Right, so ratings data (which I thought could be exported and reinserted - no?) and MySQL-dependent plugins which I would assume will be fixed in a reasonable time frame. There are always some plugins which break on SC version upgrades, there might be a few more this time, but it's not a fundamental change from a coding point of view.
> > If you believe that the transition to the new db will be completely > painless and that all users' libraries will be re-scanned and migrated > without "any" issues when the SQLite version is released, I have a > bridge to sell you. > I wouldn't expect the change in DB engine to make a significant difference to scanning, no, but I could be wrong. Looking at my library it's made no difference whatsoever - same tracks, same tags. I _would_ expect the new scanner to make a difference (although that's also looking good for me personally) and I would obviously expect incompatible plugins to screw things up for some people (e.g. people with custom browse hierarchies). Same as happens with every new version, usually things are fixed pretty quick. And I've got enough bridges, thanks :) > > This is not reason enough to drop the existing MySQL support. > Now this I quite agree with, the underlying engine should be switchable, at least via a little hacking. But LT have said that they currently have more important things to work on, such is life. Beauty of open source and all that, have at it :) > > With the SQLite engine I will end up loosing performance in my server > as I'd would have to run another db engine. > That really doesn't follow necessarily. For example, SC 7.3.3 + MySQL is currently taking around 110MB total (83+24) on my prod server. The test server has SC 7.4 (including sqlite) at 79MB. So I'm saving ~30MB (woot!) and you'll be saving something like 4MB (YMMV of course). > > Do not assume that I'm using my server and the db engine "exclusively" > for SC. No vendor should assume that their product has sole ownership of > the user's platform where is going to run. That's precisely one of the major reasons for reducing the footprint of the application! It's absolutely true that most people don't have a dedicated SC box, but I bet it's also true that the vast majority of users also don't have an existing MySQL instance on those boxes. Most are sharing with iTunes, Outlook, Firefox, IE etc. Saving memory (in most cases a significant amount) is good. -- radish ------------------------------------------------------------------------ radish's Profile: http://forums.slimdevices.com/member.php?userid=77 View this thread: http://forums.slimdevices.com/showthread.php?t=64564 _______________________________________________ beta mailing list beta@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/beta
