> 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:
> 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
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.