On Wed, 25 Oct 2006, Jesse Erlbaum wrote:
> I see the advantage of a unique key which is pure metadata (i.e.,
> without any other meaning) and consistent across servers. People have
> an expectation that the story IDs work like this and are constantly
> baffled why a story (or other object) has a different ID on a different
> server. UUID would certainly give them what they want. (FWIW, I've
> been thinking about some sort of "Inter-Krang Protocol" for a while
> which could use this, but that's another subject.) My immediate concern
> is the complexity of multiple IDs in the system.
I agree - there's danger in the complexity. I guess I'm willing to
deal with it because I absolutely have to solve this problem and I
can't think of a simpler way to do it.
> Should we drop the database IDs in favor of this UUID?
I don't think so. They're huge, for one thing - 128-bits to be exact.
We'd pretty much have to stop showing them in the UI - even if we
could fit them on the screen they're so long that user's would no
longer be able to remember them. They also won't index nearly as well
as the current IDs, so Krang would be slower.
>> - In production Joe creates foo.com/news/awesome
>>
>> - In beta I start work on a new and improved foo.com/news/awesome
>>
>> - I finish work and try to move the new story in production
>>
>> If there's no fall-back to URL-matching then import goes boom since it
>> can't have two stories with the same URL.
>
> In the situation you describe, what should be the behavior? Overwrite
> Joe's story?
Yes, I think so. That's the behavior now and I think it's pretty
reasonable.
> What if Joe doesn't want his story to be overwritten?
Then he can revert it, I guess.
> Isn't that the same problem you started with before the UUID?
It could be - depending on the user's expectation. In my example I
intended to convey that the intent of the person working in beta was
to produce a new version of the story, starting from scratch.
> It seems that a UUID would support the following use-cases:
>
> Case A:
> 1. You create a story (UUID: "123") on server A
> 2. Joe creates story "456" on server B, at same URL as story "123"
> 3. You import story 123 from server A, which results in duplicate URL
> exception
You'd rather have an exception in this case, rather than an update?
That seems like a pretty big change for Krang. Maybe this isn't too
likely for stories but I think this kind of parallel development is
happens for templates and media all the time. Media is often loaded
onto multiple systems via FTP, for example, which doesn't offer any
metadata.
> Case B:
> 1. You create a story (UUID: "123") on server A
> 2. Story "123" is copied to server B
> 3. You edit story "123" on server A
> 4. Joe changes the category of story "123" on server B
> 5. Re-import of story "123" from A to B causes (?????) story 123 to be
> moved back to original category, and content to be updated.
> 6. If another story has been created in the old URL of story 123 on
> server B, an exception will be thrown.
>
> In this situation, what does keying on URL do that isn't done by UUID?
> Is there any need to have that "fall back" anymore?
Perhaps not, depending on the use-case. One problem will be existing
beta-production pairs. When they upgrade to this release all their
objects will get fresh UUIDs - without some other kind of matching any
future imports will be a real pain.
>> I'll prevent it by making sure it won't happen, I guess. Regardless
>> of a UUID match Krang can't allow two of anything to have matching
>> URLs. If the import code can't resolve the problem then it'll just
>> have to fail.
>
> I guess you'd need a first pass to check for dups?
Probably all I need to do is catch the exception from the DB - URLs
should all have UNIQUE indexes I think.
> Also, maybe there should be an option to skip colliding objects?
> Maybe an option to link UUIDs which is default off? (I guess this
> might be the "fall back" behavior you describe.)
I can make it fully configurable. I think I'd default to having both
behaviors - first try UUID and fallback to the old method if no match
is found. I can make it so that either can be turned off, through an
option to krang_import. Sound good?
-sam
|