ckp Posted August 24, 2016 Share Posted August 24, 2016 Hi, I just starting getting into LB recently. I have hit a corrupted lunchbox.xml on start. It got corrupted for some reason when I logged off my user account with LB still open. So I restored the latest one from backup and all is well. But then I started wondering about why LB uses problematic and potentially very slow xml files. I wonder if things would be much better all around if LB switched to using a sqlite db? Has this been considered? Quote Link to comment Share on other sites More sharing options...
Jason Carr Posted August 25, 2016 Share Posted August 25, 2016 Hi @ckp, good to know about logging off. I'll have to take a look at that. I have considered Sqlite, but generally any time I bring up moving away from XML I get a lot of pushback. People like being able to see and modify the data. Quote Link to comment Share on other sites More sharing options...
ckp Posted August 25, 2016 Author Share Posted August 25, 2016 You can still see and modify a sqlite db with a free sqlite tool, but I guess it's not as easy as using a text editor. I understand that reason. If the performance/stability benefit isn't big enough, it makes sense to stick with xml I guess. Quote Link to comment Share on other sites More sharing options...
tastyratz Posted September 10, 2020 Share Posted September 10, 2020 (edited) Sorry for the necro bump, but, I actually found this thread in a search because I wondered the same question. Why on earth is Launchbox not using sqlite on the back end with this many entries? I'm going to agree that people want to edit their configs. Having it exist ONLY in a database wouldn't fly. Giant XML files though really isn't a great answer. So... @Jason Carr why not both? What if Launchbox imported XML data into a SQLite db as part of the caching mechanisms? People could still edit the XML's as needed. On start, launchbox could parse the folder for timestamp codes and whenever the timestamp of the XML differed from matching sqlite entry, the contents are re-imported. That should be a relatively quick operation but then it's a 1 time op only on changes. That could entirely be a background process AFTER LB/BB launched scraping for changes and new entries. sql back ends are light, lightning fast, editable on the fly, and significantly more scalable. XML on the front AND back end has GOT to be holding back performance. I'm sure it would make playlists and per game list stacking simple queries vs generated objects. Edit: Holy CRAP I just realized the online backend metadata.zip is a file pull of a couple giant XML file! No WONDER imports take as long as they do! I bet we're talking 100x performance delta... Thoughts? Edited September 10, 2020 by tastyratz Quote Link to comment Share on other sites More sharing options...
Jason Carr Posted September 10, 2020 Share Posted September 10, 2020 @tastyratz This has come up many times over the years, and my responses are all over the forums. There are very few performance issues that are actually with the data itself. Really, there aren't any. Delays come primarily from the media. If you run an import and turn off all image options, it goes lightning fast. Our code has been optimized many times over, and SQLite would not bring a significant performance benefit. I know, because for one thing, I have the code, and for another thing, I spent many years as a software consultant working with SQL Server, MySQL, and SQLite. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.