<div class="gmail_quote">On Fri, Sep 11, 2009 at 2:22 PM,  <span dir="ltr">&lt;<a href="mailto:f-myth-users@media.mit.edu">f-myth-users@media.mit.edu</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
P.S.  Yes, yes, if you rearrange your inputs, you&#39;ve invalidated the<br>
stored data.  I contend that this corner case is no reason to ensure<br>
lossage for people who -don&#39;t- rearrange their inputs or for people<br>
who rearrange them but keep notes about when they did so.  Ditto re<br>
udev vs kernel loading order---presumably if the data was valid in the<br>
log, it&#39;s valid in the DB, and depriving the DB of it when it&#39;s valid<br>
seems pointless.  (As does saying, &quot;grep it out of the log&quot; if the log<br>
would be wrong for the same reason.  Those people for whom it&#39;s right<br>
or who can make it right could find it very handy to have.  Not all of<br>
us have things load in nondeterministic order.)<br>
<div><div></div><div class="h5"></div></div></blockquote><div><br>That&#39;s why I suggested using the &#39;displayinput&#39; text field - that would should  be unique for each input.<br><br>Granted, it&#39;s a 64-byte column, but disk is cheap nowadays, and even with 1300 recordings like I currently have, that column would add less than  1MB to the database size - trivial IMHO.<br>
<br>J-e-f-f-A <br></div></div>