Oh, it's a keyword :)
Thanks, now I understand better what it means :)
Jean
On Wed, Jan 19, 2011 at 10:13 AM, Michael Friedrich <
michael.friedr...@univie.ac.at> wrote:
> nap wrote:
>
> What do you call a clear upset logic? Is what I try to explain in the other
> mail is so?
>
>
> UPSERT - tr
nap wrote:
What do you call a clear upset logic? Is what I try to explain in the
other mail is so?
UPSERT - try an insert, wait for a unique constraint violation
exception, catch it, do an update instead.
see https://dev.icinga.org/issues/146 for more ideas.
Jean
On Tue, Jan 18, 2011
What do you call a clear upset logic? Is what I try to explain in the other
mail is so?
Jean
On Tue, Jan 18, 2011 at 6:43 PM, Michael Friedrich <
michael.friedr...@univie.ac.at> wrote:
> On 17.01.2011 17:24, Tanguy von Stebut wrote:
> > Lemme tell you... If it happens again ;)
>
> in order to r
In fact the wy of the clean/insert is very easy, and there is no threads or
others things like that in this ndo module :
* when a broker reach a new scheduler, it ask this one to get a "full brok
data". In all of this, it begins with a broks name
"clean_all_my_instance_id" with the id of the schedu
On 17.01.2011 17:24, Tanguy von Stebut wrote:
> Lemme tell you... If it happens again ;)
in order to resolve such things, a clear upsert logic would fit best.
i have that on my todo list for icinga idoutils (possibly 1.4 in may),
so maybe you'll just need the same then ;-)
kind regards,
Michael
On 17.01.2011 16:39, nap wrote:
Duplicate on nagios_hosts? That seems very very strange, there is a
clean all before all inserts. I don't see how it can happened. If you
can, launch the broker in debug mode and send us this log when it
occurs again.
without having looked at the code - how is
Lemme tell you... If it happens again ;)
2011/1/17, nap :
> And if it happened again, is a REPLACE instead of INSERT in shinken/bd.py
> solve the problem?
>
>
> Jean
>
> On Mon, Jan 17, 2011 at 4:39 PM, nap wrote:
>
>> Duplicate on nagios_hosts? That seems very very strange, there is a clean
>> a
And if it happened again, is a REPLACE instead of INSERT in shinken/bd.py
solve the problem?
Jean
On Mon, Jan 17, 2011 at 4:39 PM, nap wrote:
> Duplicate on nagios_hosts? That seems very very strange, there is a clean
> all before all inserts. I don't see how it can happened. If you can, launc
Duplicate on nagios_hosts? That seems very very strange, there is a clean
all before all inserts. I don't see how it can happened. If you can, launch
the broker in debug mode and send us this log when it occurs again.
Jean
On Mon, Jan 17, 2011 at 4:11 PM, Tanguy von Stebut <
tanguy.von.ste...@gm
Hello again,
I've been working further on my centreon + shinken prototype, and I
encountered some real problems due to integrity violation in tables
nagios_hosts and nagios-hostgroups (duplicates again), but I didn't keep the
log, sorry !!
I had to reload my VM template to recover a nice configura
2011/1/17 nap
>
>
> On Sun, Jan 16, 2011 at 11:10 PM, Michael Friedrich <
> michael.friedr...@univie.ac.at> wrote:
>
>> On 16.01.2011 13:57, nap wrote:
>>
>> But the unique need a select before, so it's too performance impacting,
>> especially with "this" database schema. In fact the only part
On Mon, Jan 17, 2011 at 10:02 AM, Michael Friedrich <
michael.friedr...@univie.ac.at> wrote:
> nap wrote:
>
> Thanks for this. So in Mysql it's trivial, and in others it's rather
> complex :)
>
>
> In this special use case - yes. It was designed like that, and for sure not
> by a rdbms guru othe
nap wrote:
Thanks for this. So in Mysql it's trivial, and in others it's rather
complex :)
In this special use case - yes. It was designed like that, and for sure
not by a rdbms guru otherwise the algorithm on update/insert would have
been a bit more logical and performing than in originatin
On Sun, Jan 16, 2011 at 11:10 PM, Michael Friedrich <
michael.friedr...@univie.ac.at> wrote:
> On 16.01.2011 13:57, nap wrote:
>
> But the unique need a select before, so it's too performance impacting,
> especially with "this" database schema. In fact the only part where we have
> duplication ar
On 16.01.2011 13:57, nap wrote:
But the unique need a select before, so it's too performance
impacting, especially with "this" database schema. In fact the only
part where we have duplication are the "common parts" : at the
begining of all "configuration" incorporation, there are a big "clean
But the unique need a select before, so it's too performance impacting,
especially with "this" database schema. In fact the only part where we have
duplication are the "common parts" : at the begining of all "configuration"
incorporation, there are a big "clean all my instance" pass, so the only
pa
On 16.01.2011 08:33, nap wrote:
Oh thanks a lot, so I'll make it mysql backend only :)
you might check the unique key instead and adapt the schema a bit then
(not causing duplicate key violations), if it's not up to major
changes/many rows then. but i am not sure how the centreon select logic
Oh thanks a lot, so I'll make it mysql backend only :)
Jean
On Sat, Jan 15, 2011 at 6:04 PM, Michael Friedrich <
michael.friedr...@univie.ac.at> wrote:
> On 15.01.2011 13:31, nap wrote:
>
> I think I'll change the insert into replace. There are some tables that
> don't have an id for the confi
On 15.01.2011 13:31, nap wrote:
I think I'll change the insert into replace. There are some tables
that don't have an id for the configuration instance, and so duplicate
cannot be avoid.
consider that replace into is not available for postgres/oracle. you'll
need kind of an upsert logic eithe
I think I'll change the insert into replace. There are some tables that
don't have an id for the configuration instance, and so duplicate cannot be
avoid.
Jean
On Fri, Jan 14, 2011 at 5:05 PM, Tanguy von Stebut <
tanguy.von.ste...@gmail.com> wrote:
> Hello folks,
>
> I've been trying to use Shi
20 matches
Mail list logo
