<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">As usual, Josh makes good points.<br>
<br>
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.<br>
<br>
I would feel more comfortable running sql queries to verify the snapshots are being created accurately.<br>
<br>
If text-based storage moves the project forward more quickly do that for now. That would be my advice.<br>
<br>
It is your call Umesh.<br></blockquote><div><br></div><div>At this stage, it's equal time and effort going either side. So I suggest to continue with the original approach UNLESS there's an additional advantage with the other.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> 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.<br>
><br>
> 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”.<br>
<br>
</span>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.<br></blockquote><div><br></div><div>I think we can pick up the deletion of a snapshot later.</div><div><br></div><div>- Umesh</div></div><br></div></div>