In testing my use of CreateProjectVersionAttributeValue to set version attribute values, I've run into some strange behavior. The problem has something to do with how updates to said values are handled by Gemini internally. When I call CreateProjectVersionAttributeValue multiple times with the same project ID, version ID, and attribute ID, it always works the first time, but after that, it's seemingly random whether it works. Gemini always replies back in the expected way, which is to say with a filled-out VersionAttributeValueEN that also includes a new AttributeValueID, but the UI doesn't always show the new value. Rather, it sometimes displays one of the previous values. And the behavior isn't the same across attribute fields: one may rarely update, while another will almost always update.

I took a peek at Gemini's database to see what it was doing, specifically at the gemini_projectversionattributevalues. It contains every attempt I've made, with each subsequent attempt being given a later timestamp and attributevalueid. Thus, if Gemini were to always use the latest value, things should be fine. I suspect, however, that it's choice is a bit less deterministic, which is causing my problem.

And that brings me to CreateProjectVersionAttributeValue versus UpdateProjectVersionAttributeValue. Should I only use the latter method when updating extant values? If so, then the former should probably error out in that case instead of happily accepting the request as it currently does. That said, since there's no way to see the history of the attribute values (which means that from the user's POV, there's one field that always exists and either has a value or doesn't, and that value can be changed), I'm not sure that update needs to be distinct from create all. Unless I'm missing something, which I seem to be doing a lot of lately....

Thoughts?