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


Reply via email to