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

Support forum for Nagios Core, Nagios Plugins, NCPA, NRPE, NSCA, NDOUtils and more. Engage with the community of users including those using the open source solutions.
Locked
Guest

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

Post by Guest »

This is a multi-part message in MIME format.
--------------090202020205050309010302
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

Hendrik Baecker wrote the following on 22.10.2009 08:25:
> Yes it looks nicer and will keep the code cleaner. Also I like the fact
> to keep the work on the database.
Yep because this is a MySQL only "feature" of case insensitive
comparison. Oracle and Postgres do case sensitive comparison by default.
So considering the fact that NDOUtils will catch on more rdbms some time
in the future you have to consider that this could lead into possible
errors if you do not prepare the code for that.
That is one of the highly MySQL dependant "features" of NDOUtils and
then changing to e.g. Postgres and wondering why queries are failing.
Just as a thought as I have been through all of this already.
>
> 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.
It's not only this fix there are also several other statements and
queries which need to be adapted to hand the work over to the database.
many of those ideas would have to break up the code completely but well
time will tell.
> Yeah - I regarded the ticket some days ago and wasn't sure if it would
> be good to break the historical refs to other tables.
> Renaming a host in Nagios will loose all history and is a little pain
> but regarding the "feature" to keep the object_id within ndoutils after
> a nagios object renaming will cause a dangerous mix up between two
> different nagios objects into one ndoutils object. That was the point
> where I was sure to do it like nagios ;)
afaik there are some complaints about nagios doing it that way. maybe
we'll go into the other direction and handle "services" as "SERVICES"
and reversed. Therefore a core modification would be necessary and
having MySQL, there wouldn't have been the need of a query change. For
Postgres and Oracle, to_lower on the param value will to the same trick.
> Bad news - Since many month there is a "read Ton's Blog to see what they
> have done" on my ToDo list. This task often felt of because less time.
If I told you that I won't commit patches for NDOUtils until you rewrite
the code to libdbi and giving me the opportunity to diff with Icinga and
also the repository changes finally to GIT what would you do... kill me
instantly next week on OSMC or relax and read Ton's blog? ;-)

Kind regards,
Michael

--
DI (FH) Michael Friedrich
[email protected]
Tel: +43 1 4277 14359

Vienna University Computer Center
Universitaetsstrasse 7
A-1010 Vienna, Austria


--------------090202020205050309010302
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit







Hi,

Hendrik Baecker wrote the following on 22.10.2009 08:25:

Yes it looks nicer and will keep the code cleaner. Also I like the fact
to keep the work on the database.


Yep because this is a MySQL only "feature" of case insensitive
comparison. Oracle and Postgres do case sensitive comparison by
default. So considering the fact that NDOUtils will catch on more rdbms
some time in the future you have to consider that this could lead into
possible errors if you do not prepare the code for that.
That is one of the highly MySQL dependant "features" of NDOUtils and
then changing to e.g. Postgres and wondering why queries are failing.
Just as a thought as I have been through all of this already.


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.


It's not only

...[email truncated]...


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