Hologram wrote: ↑Tue Feb 07, 2023 9:14 am
How bad is it to break compatibility? If done once every decade or so and the old version keeps available for download, then it may not be as bad, right. Give a prompt message for models created in version X.X and below. Or, write conversion code (which sounds easier said than done).
"Persistence of data" and "data ownership", I have to be a control over file formats, if not all my past work is simply a "bunch of digital bits".
It is another aspect of "programmed obsolescence" and similar aspect.
Not too far in time there were an Indian user (from India as there is even some ambiguity) that has all his works vanished by a modification in FreeCAD that has made his past work unusable with new versions, luckily developers have reverted the behaviour and made a some changes to permit old file works as expected, very "responsible move" not so common in OpenSource.
IMHO "format stability" is probably one of the main goal if you want to make a functional program, that will not interfere with evolution, but "format changes" has to be considered very carefully, so prior to make a "format change" better to think even "future expansions" as you could incorporate more flexible mechanism other than "version check" in a format.
Take as example in some "complicated software" you can reuse old code simply stating a "compatibility level" as example if you have made a complex figure using Tikz in Latex you could specify that you will use "version 1.6" instead of "version 1.8" that is what you have installed, but the context is "document creation" in scientific environment where "long term stability" is a "requisite" if not every research paper will be "vanished" and past research will be "unaccessible" to future researcher.
Hologram wrote: ↑Tue Feb 07, 2023 9:14 am
How would SQlite databases deal with deleted edges and undos? Won't it be populated with entries that no longer exist? At some point the database also needs to be cleaned (e.g. when closing FreeCAD do a check for unused geometries).
You could have two level, using transaction, undo tree is transient, so you decide to "start transaction" and the model is saved in the "model history" as example when starting modifying a solid, then modify the solid and this is saved in the volatile undo tree, when finished you "stop transaction" and the new solid is saved in the file. It your responsibility what to keep and what you loose.
It is a flexible way that will permit also if the database is external and distributed like in a working environment to "block a part" and release after the modifications, if you base the "topology manager" using "SQL queries" you could have a reasonable way to use an "internal Database" or an external distributed one.
This will solve even some request about concurrent modifications, done by different people on the same "complex design", but as said this is a "big change of perspective", and probably much more discussions and brainstorming has to be done.
I'm not a database expert, I have only played with them sometimes and made some works to keep some "customer archive" and "repair story" in automotive sector in a precedent life.
Regards
Carlo D.