Re: A draft proposal for UUIDs

Hi Steve

On Tue, 2011-08-16 at 09:48 -0400, Stephen Woodbridge wrote:
[snip]
> > Now, if some interface code allows the user to create INDIs, say, them
> > they have to be flagged as having a different UUID. Or do they?
> >
> > If the original UUID belonged to the source, then yes, since the new
> > INDIs are coming from a different source.
> 
> I think this is the correct answer. the UUID belongs to the source of 
> the import action the created the data when the import did not have 
> UUIDs of its own.
> 
> Adding a UUID for the import action would then allow all the data to be 
> later purged if it needed to be so there might be value in adding a UUID 
> to the import even if the imported data already has UUIDs.

I think we're getting things clearer now.

To summarize: For a given db, each source which contributes records must
be separately identified by a UUID, with that UUID attached (somehow) to
each record imported.

That means various types of reports:

o Pick 2 UUIDs and process (e.g. compare, update, export, delete) just
the records belonging to those UUIDs.

o Pick 2 UUIDs and flag records such that data with (from) UUID #1 is
deemed more reliable that data with UUID # 2. Clearly both datasets are
preserved.

o Pick 1 UUID and process (e.g. update, export, delete, ...) just the
records belonging to it.

o Many others possibilities ...

Good stuff!

-- 
Ron Savage
http://savage.net.au/
Ph: 0421 920 622