[dev] [commits] Horde-Hatchery branch master updated. 02e85eac62ebef1a704bf89180c24d2b61cc6a46

[Chuck Hagenbuch]

Quoting Michael Rubinsky <mrubinsk at horde.org>:

>>> http://git.horde.org/diff.php/content/lib/Tagger.php?rt=horde-hatchery&r1=3cf6904036b3088c3d1c204097c7e6f2557856b5&r2=02e85eac62ebef1a704bf89180c24d2b61cc6a46
>>
>> I may have been wrong on this one. Maybe we should enforce lowercase
>> tags, or maybe use case-preserving behavior like the OSX filesystem.
>> Otherwise we have to ensure that the db string field is
>> case-sensitive, or we can get an error on the unique tag_name index.
>
> My intention with this was to implement case-preserving behavior in
> the sense that if the tag already exists in the DB, the case of the
> original tag is used regardless of what the next user is typing.  It
> was the cleanest way I could think of without forcing tags tolower.
> Are you seeing an error somewhere?  It seems to be working OK on this
> end.

Yes, it was one of these two:

$tagger->ensureTags('work', 'Work');
$tagger->ensureTags('Work', 'work');

One of those works, the other generates a unique key violation. I  
didn't track down exactly why. Might be relevant that this was using  
the SQLite adapter.

> FWIW, the sites that I'm familiar with usually force tags to lower
> case. Flickr does this as well, with the exception that if your the
> user that tagged the image, you are shown the "raw" tag, while the
> rest of the world sees the normalized/lower case tag.

I'm more open to this way now, at least the lowercase one. When I  
looked at the normalization in freetag, it didn't really seem like it  
would work to me, but I might have just misread it.

-chuck