Exhibition/About seems broken - stable keys

[Antranig Basman]

Terribly sorry to have broken the view. On balance I thought it might be 
quicker to go forwards rather than back - but if it will take too long 
to switch over to IDs I can try to back out my change and investigate 
what it changed in terms of the request sent to CouchDB. The Couch URL 
which is being used "looks reasonable" in that it is hard to see how it 
might be different to the URL which was being sent before the change but 
presumably there is some subtle difference in the exact encoding which 
is being applied to the JSON data.

That said, if we *do* go forwards, I think it would be important to use 
a stable domain-specific key rather than the doc UUID. It would be 
impossible to operate stable URLs for artefacts and other entities 
otherwise. Hugues has told us how to derive these for McCord and it is 
an essential requirement of any other integration that we could do this 
for another institution. So this is certainly something we will do for 
0.5 but the question is whether it makes sense this week.

Sorry for the regression,
Antranig.

On 11/02/2010 09:22, Colin Clark wrote:
> Hey,
>
> Couch UUIDs are probably the only stable identifier we can use without making assumptions about the structure of the museum's data. It makes sense to me to go ahead and do this, though I would have perhaps preferred postponing that change until after the 0.3b release for Hugue's pilot.
>
> Antranig, I think your commit did indeed break the Exhibition About page. The question I have is how we should fix this; Yura, you mentioned that you think the switch from keying by title to UUID is trivial. Do we know if this change will also fix Exhibition About?
>
> Regressions, regressions. :(
>
> Colin
>
> On 2010-02-11, at 3:43 AM, Antranig Basman wrote:
>
>> Could I suggest in the meantime that instead of issuing titles in URLs we instead use document UUIDs, which will head off risks of encoding issues of this kind? Titles are not a stable element of the data domain.
>> In truth, we should be deriving a proper domain-specific stable key, but I don't know enough about the McCord set to find this right now.
>
> ---
> Colin Clark
> Technical Lead, Fluid Project
> http://fluidproject.org
>