[GNC-dev] Normalizing live data, a suggestion for discussion

[Wm]

On 01/02/2019 19:17, Stephen M. Butler wrote:

Ummm, Stephen M. Butler I don't think you were my intended audience.

Let me put you down gently.

> It might be better to have a standardized test file that folks could
> download, and run their scenario against.

Nope, we can do that already, I was addressing other realistic situations.

> However, there are situations that arise where the only solution is to
> look at the original file.  In that case some obfuscation would be
> helpful.  I would think that memos and descriptions would also need to
> be randomized.

My suggestion is they are zapped, no personal stuff at all

> After a careful read, I realized you did intend to
> randomize the transaction amoun  ts (which would have to be careful to
> ensure the DR/CR remained balanced.

I'm one of the more intelligent people here, the tx will remain balanced.

> Otherwise, one could at least get
> the total Assets/Liabilities/Income/Expense values known for the
> submitter.  That may be sensitive information.  I know that I've shared
> some information that later reflection was "did I really give them that!"

Ummmmm

> Now, to the XML vs SQLite argument.  Whatever script is applied to one
> could easily have a counterpart that would apply to the other.  You
> wouldn't have to manually (informally) edit the XML.  A known script
> should provide a known outcome.

Not true in reverse if someone throws in some numbers no other person 
knows about.  Think about diminishing returns.

I can't correct this fucked up quote below, must be a Mexican border 
issue, sigh.  Looks like a Trump voter, fucked quotient in general.

 >I suspect that many folks are using an
> XML back-end and would rather not fiddle with a database back-end.

We know know that, we ask for a specific db when we need to test stuff.

I've given up correcting the quoting, sorry, folks.

  I'm
> in that camp even though I'm a trained Oracle DBA and spent a couple
> decades using that back-end professionally.

We are unimpressed unless you contribute.

Some of us also think training may have been wasted time if you end up 
not knowing much about databases.

> I think the first step is having a standard test file that a use could
> apply to their favorite back-end, run their scenario, check the
> results.

Wrong, please read what I said before.  Grrrr.

I hate it when someone so obviously doesn't read.

> If the problem is verified, then we have pretty good evidence
> the problem is in the application.  If the problem doesn't show up, then
> it indicates the problem may be in the data.  That would require a "data
> forensic expert" (aka developer or some assistant) to look deeper into
> the user's data file.  In that case a good obfuscation tool would come
> in handy.

I'd say something obviously rude around now but Liz would zap me instead 
of the fool if past rules are anything to go by :(

I'd like someone with a clue to attempt an answer.

-- 
Wm