Hi Josh, 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. >> >> >> By 'ports', do you mean 'registry.ports' table? If yes, then I disagree. >> It's actually 'registry.snapshot_ports' table. A snapshot has nothing to do >> with the original registry "tables". >> > > That was a suggested design; if you're already doing it differently then I > guess you don't need a design. I disagree with the last sentence though, a > snapshot can be viewed as precisely the state of the original tables at a > previous time.
This is on the lines what I had in mind regarding a snapshot. Also, we are not using version and revision. Even going by the literal >> meaning of a snapshot, it should not have a key or id linked to something >> that can change over time. It's simply the present state. >> > > The row in the ports table would not change over time, it would simply > persist until no longer needed. If we ever get the ability to install old > versions then that information would come in handy. I meant when the port gets updates, the row in the 'ports' table will change but not in 'snapshot_ports' table because for a particular snapshot, the state has changed. But I think it's clear now. And yes, version and revision can help in restoring older versions of ports present in older snapshots. > Later, I am planning to keep information on the manual portgroups in the >> snapshot, if there are any. >> > > What would this information be used for? > I am under the impression that a user can categorize and classify the ports into portgroups, so it should be better if we migrate them too. Though, it seems highly unlikely now that I write and quite possible I need to learn about them more. Regards, Umesh Singla