That's not simple for the average user, I know.Ī good import/export utility in OpenSong would help ease some of the issues of complexity or movement of sets and songs between computers. I have caught typos in songs before they were projected and would bring up an editor to fix it in the file, then use Q (Quick Song Add) to put the corrected version into the set. I've also taken advantage of the simplicity when in presenter mode. Files can be easily moved between systems, for one thing.
There is that simplicity in the individual flat-file format that is still appealing for its flexibility. That is adequate for a relatively static data item. This is for the song search - searching Bibles is done by pre-building a simple word index. If the song has a custom style with a large background pic, a lot of unnecessary data gets read in and that slows it down even more. The built-in search opens each song file sequentially, parses the XML and then looks for the search text. You mentioned OpenSongSearch searching is something that OpenSong does very poorly and I know you were driven to write OSS because of that.
That's why I mentioned the FolderDB discussion I've had with cozmic in my previous 's not out of the realm of possibility at all. I see definite advantages to having a database involved. I can write simple SQL statements, but my database knowledge is definitely limited.īelieve me, I have spent many hours debating both sides of this argument with myself. In fact, your input is very valuable since my programming background is in scientific and real-time systems. Sorry for the length of this post, but I think it's one of the most important design criteria for the future of OpenSong. So, at least for our use, we would very much like to see a database integrated into OpenSong.even if the xml file structure were maintained for certain things and one could run a "database update" that copies the contents to an integrated database for certain operations that work better with a database. The pre v1.1 folderDB simply doesn't work when we try to add certain songs and the non-folderDB method remains hopelessly slow for our song database of 2,500 songs. With respect to the use of pre v1.1 folderDB and refresh songs, etc., that still doesn't work for us.
#Opensong song database full#
I don't say that it's trivial, because SQL can become quite complex, but in comparison to reporting off of directories full of xml plain-text files, it really could be called trivial. The beauty of a database is that once the info is in there, manipulation and reporting are greatly facilitated by external tools. At the moment, it doesn't store what's needed to keep track of CCLI stuff or other kinds of reporting, but certainly that information is possible to store and if someone needed desparately to create some sort of reporting activity, I'd suggest in the short-term, if you're a coder, to hack together an addon like OpenSongSearch for that sort of thing. The lack of a DB is one of the reasons I wrote OpenSongSearch. So, I must disagree with a blanket statement that xml plain text files create/keep all things more simple.certain things yes.but definitely not all. simple (xml plain text) files leverage well-known file manipulation procedures.īut.there is a LONG list of activities that are made more difficult/more complex/slower due to an xml-simple-file-based storage mechanism.
#Opensong song database professional#
First of all, I need to plead guilty to being a professional database administrator in my pre-missionary life.so I'm clearly biased.īut the point I wanted to make is in response to "Each song is in separate file because it helps to keep OpenSong simple and easy to use." I will agree that for certain operations, notably when one has to edit a single song outside of OpenSong or copy songs from one folder to another, add a set of songs from someone's key, etc. I wanted to weigh into this discussion.not to be a pain in the rear or to start an argument, but because I think that integrating a database into OpenSong is a vital design decision for the future.