[GSoC] migration

[Bradley Giesbrecht]

> On Aug 10, 2017, at 9:31 AM, Umesh Singla <umeshksingla at macports.org> wrote:
> 
> 
> 
> On Thu, Aug 10, 2017 at 2:54 AM, Joshua Root <jmr at 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