Re: [Nagios-devel] Case-insensitive objects in NDOutils

[Guest]

--Apple-Mail-63-873594241
Content-Type: text/plain;
charset=US-ASCII;
format=flowed;
delsp=yes
Content-Transfer-Encoding: 7bit


On 22 Oct 2009, at 07:25, Hendrik Baecker wrote:


> Am 22.10.09 05:33, schrieb Ton Voon:
>> Quick note. I saw this change below and wondered if this is best
>> done in
>> the database. For Opsview, we made this change about 2 years ago
>> for the
>> same effect:
>>
>> ALTER TABLE nagios_objects MODIFY name1 varchar(128) COLLATE
>> latin1_bin NOT NULL default '';
>> ALTER TABLE nagios_objects MODIFY name2 varchar(128) COLLATE
>> latin1_bin default NULL;
>>
>> The code then stayed the same. Also it means anything trying to
>> read the
>> data doesn't need to remember to specify BINARY either.
>>
> Yes it looks nicer and will keep the code cleaner. Also I like the
> fact
> to keep the work on the database.
> One question back: If it uses COLLATE latin1_bin, the default sort
> thing
> would be binary which is OK but afaik there are other associations
> with
> the charset
> (http://dev.mysql.com/doc/refman/5.1/en/ ... collation-
> charset.html).
>
> What will happen on a simplified chinese as default charset mysql if
> ndoutils would try to set latin1_bin as collate?
> There are missing MySQL international experiences on my side, but is
> it
> a good practice to rule the charset?
>
> Further comments on this?
> I would prefer a database way to do this, but I wouldn't like to force
> the user to use a charset which he doesn't know/like/can't use.

This is a fair point. Would

ALTER TABLE nagios_objects MODIFY name1 varchar(128) COLLATE
utf8_bin NOT NULL default '';
ALTER TABLE nagios_objects MODIFY name2 varchar(128) COLLATE
utf8_bin default NULL;

make more sense then?

Can anyone with more mysql knowledge explain?

Ton


--Apple-Mail-63-873594241
Content-Type: text/html;
charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

On 22 Oct 2009, =
at 07:25, Hendrik Baecker wrote:Am =
22.10.09 05:33, schrieb Ton Voon:Quick =
note. I saw this change below and wondered if this is best done =
inthe database. For Opsview, =
we made this change about 2 years ago for =
thesame =
effect: =
   ALTER TABLE nagios_objects MODIFY name1 varchar(128) =
COLLATElatin1_bin NOT NULL =
default ''; =
   ALTER TABLE nagios_objects MODIFY name2 varchar(128) =
COLLATElatin1_bin default =
NULL;The code then =
stayed the same. Also it means anything trying to read =
thedata doesn't need to =
remember to specify BINARY either.Yes it looks nicer and will keep the code =
cleaner. Also I like the factto keep the work on the =
database.One question back: If it uses COLLATE latin1_bin, the =
default sort thingwould be binary which is OK but afaik there are =
other associations withthe charset(http://dev.mysql.com/doc/refman/5.1/en/ ... rset.html=
).What will happen on a simplified chinese as default =
charset mysql ifndoutils would try to set latin1_bin as =
collate?There are missing MySQL international experiences on my =
side, but is ita good practice to rule the charset?Further =
comments on this?I would prefer a database way to do this, but I =
wouldn't like to forcethe user to use a charset which he d

...[email truncated]...


This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]