> On Aug 10, 2017, at 9:31 AM, Umesh Singla <umeshksin...@macports.org> wrote: > > > > On Thu, Aug 10, 2017 at 2:54 AM, Joshua Root <j...@macports.org> wrote: > On 2017-8-10 04:59 , Umesh Singla wrote: > Hi > > I was trying to streamline the whole process and I felt the need to have the > snapshot as a separate entity just like a reg_entry or a reg_portgroup is, > that is, "registry::snapshot" with a bunch of functions like create, get, > list_all etc. I think this might help in writing the whole thing from a > higher Tcl level. > > But then again, a snapshot is not something coming directly from the > database, so I'm not sure how to keep it. Can I get your view on this? > >> Well, you already know that my view is that it would be far simpler to store >> the snapshots as a text-based format, rather than write and modify a large >> amount of non-trivial C. > > I think what Josh means here, is a complete text-based dump of the current > state in a file and then using restore, something like what we currently > expect our users to do themselves.
As usual, Josh makes good points. A text-based database is less convenient to query. I really don’t see why storing the information in a database should be challenging. But I’m not writing the TCL or C. I would feel more comfortable running sql queries to verify the snapshots are being created accurately. If text-based storage moves the project forward more quickly do that for now. That would be my advice. It is your call Umesh. > It could be useful in a case when a user wants to completely re-install the > OS from scratch and then, a text-formatted file can easily be backed up for > use by restore later. We can argue that keeping in registry.db is also > similar to keeping in a file, but the interface we are providing a user help > migrate are bit different. Because it is not intuitive to take a dump of > registry.db manually but running a take_snapshot command is. > > But if you are set on doing this in the sqlite database, the relational way > of doing it would be to add: > > 1. A table of snapshots, consisting minimally of names and ids > 2. A table associating snapshot ids with port ids on a many-to-many basis > > Under this model, the set of currently installed ports would be just another > snapshot, albeit one with a special meaning. The activation state of each > port would have to move from the ports table and become per-snapshot (maybe > stored in the second table?). > > And yes, you would need procedures to manipulate this stuff from Tcl as you > suggested above. And the existing code would need to be updated to only > remove ports when they are no longer referenced by any snapshot. > > And then again, I am sensing a confusion with the idea of snapshot with Josh, > like when he says "remove ports when they are no longer referenced by any > snapshot”. I think Josh is referring to 3NF normalization (third normal form). I don’t think this use case warrants this complexity. I think it is fine for two snapshot id’s to reference the same port+variant combination. When a snapshot id is deleted, cascade delete. — Brad
