Front page | perl.gedcom |
Postings from August 2011
Re: A draft proposal for UUIDs
Thread Previous
|
Thread Next
From:
Stephen Woodbridge
Date:
August 15, 2011 18:59
Subject:
Re: A draft proposal for UUIDs
Message ID:
4E49CD95.2080308@swoodbridge.com
On 8/15/2011 6:06 PM, Ron Savage wrote:
> Hi Steve
>
> See below
>
> On Mon, 2011-08-15 at 09:12 -0400, Stephen Woodbridge wrote:
>> On 8/14/2011 11:41 PM, Ron Savage wrote:
>>> Hi Folks
>>>
>>> http://savage.net.au/Perl-modules/html/genealogy/uuid.html
>>>
>>> Let the replyfest begin!
>>>
>>
>> Ron,
>>
>> Overall this is a great start, here are some comments:
>>
>>> Importation of GEDCOM data
>>>
>>> When a file of GEDCOM data is imported, various cases arise:
>>>
>>> o Importation into an empty system
>>>
>>> In this case, UUIDs do not need to be geneated.
>>
>> I think this is only true if the empty system does not support UUIDs,
>> otherwise it needs to create at least one top level UUID to reflect the
>> importation. This would be identical to the case of having an empty
>> system and adding INDI(s) to it.
>
> Hmmm. Not sure about this.
>
> I guess this raises the question: Is that UUID meant to represent the
> source or the new db?
This is a good question and I tried to answer it with my implied question:
Given an empty system, what happens when you add the first INDI?
I would assume that the act of importation would be similar to creating
an INDI. Also if the imported GEDCOM had UUIDs then you would import
them. Would you create an extra import action UUID, probably not needed,
but I think you are right to create one for the import action because
all imported entities would then inherit that UUID and be tagged for the
future that they came from that act.
> I was thinking only that a UUID would be generated on demand, but I'll
> reconsider.
>
> Pauses a moment ... The source I'd say, so yes, probably better to
> generate one at importation time.
>
>> Nice job.
>
> Thanx. Errrr - Your reply stands out in the deafening silence :-)).
>
OK, well I'll throw out another thought that I had on this for
discussion. It has to do with optimization of UUIDs for storage purposes
in the GEDCOM. This seems risky, as it implies looking up some hierarchy
of structure that is not clear to me to find the UUID for some given
item. While this might be very straight forward in an object oriented
system that supports inheritance, I'm concerned that this might be:
1. difficult to do in/with a GEDCOM file
2. while it decreases spatial complexity, it increases algorithmic and
time complexity
3. it might be error-prone or hard to verify algorithmic correctness
4. it might be expensive to find the UUID for a given item
OK, so these concerns are somewhat abstract at the moment, I think they
warrant at least some thought and you might want to consider supporting
GEDCOM import/export where all items are tagged with their UUIDs.
Although, I can imagine that that would double or triple the size of the
GEDCOM generated. If you can generate both, then this could be used to
generate test cases to validate the correctness of other software.
Anyway I did mention this originally, because it seems like a valid
optimization, so I'm not suggesting that you change anything, but I
thought it worth while to raise this point to see what others might
think about it.
-Steve
Thread Previous
|
Thread Next