Timeline for Regrouping several application files into one
Current License: CC BY-SA 4.0
13 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 28, 2022 at 7:55 | vote | accept | f222 | ||
| Oct 25, 2022 at 13:49 | comment | added | Laiv | @f222 Rather than writing "strings" in a specific format (csv, tsv, json, xml, etc) just write all the bytes. Make binaries :-). If possible. | |
| Oct 25, 2022 at 13:15 | comment | added | Doc Brown | If you don't want to change most of your existing file formats, you could use a BLOB record for each file inside the SQLite DB, then you keep the ability to read and write the data in the same granularity as you do today. And creating a new SQlite file with the right schema is trivial: prepare an "empty" SQLite database file which contains only the schema plus any standard value tables, then simply copy that file. | |
| Oct 25, 2022 at 13:06 | comment | added | f222 | @DocBrown my issue with using SQLite is first that I will need to reformat some data (and for some of the project parts I have a lots of key-value maps which might be cumbersome to store in a DB). And also with a zip file, when the user creates a new project I know I can easily create a zip file, I dont know how easy (or hard) it can be to create a SQLite file and populate the schema in the DB before using it. | |
| Oct 25, 2022 at 12:40 | comment | added | f222 | @Laiv One of the Issue I have with that is that I would prefer to obfuscate (at least a little bit) the files / architecture. I know that security through obscurity is not a good thing but sometimes we have user who, instead of calling support when they have an issue, modify the files by hand (which breaks everything) and then call support. I think hiding just a bit the files might help even if it's not a perfect solution. | |
| Oct 25, 2022 at 12:37 | review | Close votes | |||
| Nov 10, 2022 at 3:08 | |||||
| Oct 25, 2022 at 12:32 | comment | added | Doc Brown | ... because if you can change the file format, you could use a lightweight file-based database system like SQLite. That gives you the ergonomics of keeping everything in one file with the power of reading and writing arbitrary parts of it in a random-access manner, without corrupting your data in case of an application crash. If there is some kind of standard, then this. | |
| Oct 25, 2022 at 12:32 | comment | added | Laiv | Q3: Wouldn't be easier to define a descriptor? Say an XML or Json (or make your own format) per project, holding the reference to all the files involved? That's your meta-project file. An index or map. | |
| Oct 25, 2022 at 12:31 | comment | added | f222 | @DocBrown there are several steps in the project each step read some files and write other files. There is only one step done at a time so usually I load just the needed files at the beginning of a step and unload them at the end. I don't need to open all the files at the start of the program. Changing the file format might be an option but I don't really see why doing this would change something... | |
| Oct 25, 2022 at 12:19 | comment | added | Doc Brown | Q2: is changing the file format(s) an option? Or do you want to keep as much as possible from the current file formats inside the single file? Please clarify. | |
| Oct 25, 2022 at 12:17 | comment | added | Doc Brown | Q1: Does it make sense for your C++ application to load all the files at once at the beginning, and save them at once, for example, when the user presses a "Save" button? Or do you need to read and wrote individual files? Please clarify! | |
| Oct 25, 2022 at 11:10 | answer | added | Hans-Martin Mosner | timeline score: 2 | |
| Oct 25, 2022 at 10:28 | history | asked | f222 | CC BY-SA 4.0 |