On 2017-8-11 02:31 , Umesh Singla wrote:



On Thu, Aug 10, 2017 at 2:54 AM, Joshua Root <j...@macports.org <mailto: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.

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

What confusion exactly? A snapshot is simply a set of ports (by which I mean rows in the 'ports' table, with a unique combination of name,version,revision,variants). When nothing references a row any more, it needs to be deleted.

- Josh

Reply via email to