<div dir="ltr">Thanks for the replies guys<div><br></div><div>I only saw this now as my Smalltalk/Gemstone mails go to a folder that I always forget to check :(</div><div><br></div><div>But I appreciate the replies!  In the end I found a solution.  I will post what I did here when I have a bit more time and you can critique it :)</div><div><br></div><div>Thankful for the community</div><div>Dirk</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 13 Jul 2021 at 23:16, Jaroslaw Podgajny <<a href="mailto:j.podgajny@gmx.net">j.podgajny@gmx.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div>
    <p>Hi Dirk,<br>
    </p>
    <div>On 13/07/2021 11:43, Dirk Nel via
      GemStone-Smalltalk wrote:<br>
    </div>
    <blockquote type="cite">
      
      <div dir="ltr">Hi all
        <div><br>
        </div>
        <div>I'm currently working on some data anonymization stuff in
          our GemStone production database.  I'm thinking of strategies
          of having certain portions of code just running in the prod
          Db.  As we restore our prod Db into our test Db this is
          difficult.  One idea that I had was to let the code that
          should only run in prod live in topaz scripts on the host
          instead of in the Db.  Any other thoughts about this out
          there?  And maybe just about data anonymization and Gs in
          general?</div>
      </div>
    </blockquote>
    <p>One solutions would be so called Tokenization. You would create
      mapping to consistently transform confidential data from one
      string/token to another, e.g. 'Mitsubishi' translated into 'Zork
      Company'. This process would run as part of your test DB bootstap
      code. One advantage of this solution is preservation of human
      readability of data. A disadvantage is costly nature of the
      transformation if the data set is not normalized, i.e. strings are
      refrerenced directly rathern than via a unique container
      Counterparty object, as an example). Additionally naive equality
      tests in the code would fail in test, which is probably a good
      thing ;).<br>
    </p>
    <p>Another option that does not suffer from costly performance
      characteristics of Tokenization is so called Application Level
      Encryption. In this solution you encrypt your confidencial data
      and only provide access to the key in the production environment.
      In your test DB environment users would only see the crypto
      strings. One of the disadvantages is that the data is no longer
      human readable. There is also a whole domain of complexity around
      key management to deal with.</p>
    <p><br>
    </p>
    <p>Regards, <br>
    </p>
    <p>Jaroslaw.<br>
    </p>
    <blockquote type="cite">
      <div dir="ltr">
        <div><br>
        </div>
        <div>Regards</div>
        <div>Dirk</div>
        <div><br>
        </div>
        <div><br>
        </div>
      </div>
      <br>
      <fieldset></fieldset>
      <pre>_______________________________________________
GemStone-Smalltalk mailing list
<a href="mailto:GemStone-Smalltalk@lists.gemtalksystems.com" target="_blank">GemStone-Smalltalk@lists.gemtalksystems.com</a>
<a href="https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk" target="_blank">https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk</a>
</pre>
    </blockquote>
  </div>

</blockquote></div>