Re: [Gnumed-devel] schema verification

[Karsten Hilbert]

> > I am not sure I understand the real world relevance of such
> > esoteric arcana no one in his right mind is ever going to
> > look at unless forced to by abysmal circumstances.
> > 
> > Karsten

Sometimes I'm a little straight, don't take it personally, please :)

> Well, mine was not the decision to produce and supply the reference
> information in the fingerprint.

What I was referring to: the fingerprint produces something people
will only want to use in the worst of circumstances, namely when
fixing/restoring broken databases, for which case it is hardly
relevant to overly optimize, let alone asthetize.

After all, the fields - while human readable - are not *meant* to be
read. They are meant to be compared by diff.

To that end it is important to NOT change the field order if at all
possible such that stored fingerprints may match recent ones (or
else there would be no use adding fingerprints to the tarball ;-)

Of course, the data field content will only be useful if comparing
the very same database before/after restoring. The hash and schema
structure will/should be the same, however.

What I'm saying - IF people need to look at this sort of arcane
information they DO need to know what they are doing anyway.

> Mine was only the suggestion to take what is there, and to disambiguate
> the hash as to whether it represents a hash of
> 
>       the *structure* (tables, column types) of the database
> 
> (which is what it is, but may not seem to be, as compared to the
> alternative of a hash of)
> 
>       the entirety of the database
> 
> which AFAICT is the hash that is generated and which one would send when
> processing one's database backup via gnotary.

I now better understand exactly what you were aiming at.

It's just not like that would be without drawbacks either.

Karsten
-- 
NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!               
Jetzt informieren: http://www.gmx.net/de/go/freephone