Sync dependencies

[yhabteab]

Requires

• Sync dependencies to Redis icinga2#10290

[julianbrost]

I'd suggest renaming that column to something like dependency_children. affected_children makes it sound like this should be some dynamic value, but it's actually a static config value and whether this number of children actually affected is shown by affects_children in the state tables. (Same for the service table and the PostgreSQL schema of course.)

@nilmerg Any objections to such a change as it also affects web?

[nilmerg]

My only objection is against your reasoning. It's not inside the state table but in the config table and hence one shouldn't assume it being a dynamic value.

[julianbrost]

I'm just saying that a name that says that it's the total number of checkables that have a dependency on this one better reflects what's stored in the column. With the name affected_children this feels more like "if the corresponding affects_children is true, then this is the number, otherwise it's a meaningless value" to me.

[nilmerg]

It is a meaningless value. We limit it to 1001 after all. Or don't we? This is even more important for Web, actually. :P

What I want to say, at the current stage (with limit) the name always lies, whatever it's called.

If the limit is lifted by now, then total_children fits most, right?

[julianbrost]

At the moment, no such limit is implemented. That would have been more of a safeguard against many objects with many children. However, limiting that makes little sense if we need to update the reachability of each child with every state change of the parent anyways (I'm still worried that this might actually cause problems).

[julianbrost]

So now I have two places things that I suggest to rename in the schema:

1. affected_children -> total_children, see Sync dependencies #889 (comment)
2. redundancy_group -> redundancygroup in all table and column names, see Sync dependencies #889 (comment)

Both affect web, so that should be coordinated. @nilmerg Are you fine with both of these changes? And if so, shall we just update this PR and Icinga/icinga2#10290 and ping you once done?

[julianbrost]

I'd rename this table to redundancygroup (and redundancygroup_state respectively) for two reasons:

• Consistency with other already existing group tables:

  icingadb/schema/mysql/schema.sql

  Line 229 in a77498d

  CREATE TABLE hostgroup (

  icingadb/schema/mysql/schema.sql

  Line 395 in a77498d

  CREATE TABLE servicegroup (

  icingadb/schema/mysql/schema.sql

  Line 1027 in a77498d

  CREATE TABLE usergroup (

• Makes the following special-casing for the table name unnecessary ¹:

  icingadb/pkg/icingadb/v1/dependency.go

  Lines 16 to 19 in 8fdf0a2

  	// TableName implements [database.TableNamer].
  	func (r *Redundancygroup) TableName() string {
  	return "redundancy_group"
  	}

Footnotes

1. I presume that's currently necessary due to the inconsistency between Redis (icinga:redundancygroup, i.e. no separator in redundancygroup) and SQL (redundancy_group, i.e. with a separator), otherwise the Go type could also be named RedundancyGroup. ↩

[yhabteab]

1. otherwise the Go type could also be named RedundancyGroup. ↩

No, it cannot! The Redis keys are generated dynamically based on the Go type name and that would result in icinga:redundancy:group which does not exist in Icinga 2.

[julianbrost]

"Otherwise" as in "if it actually was icinga:redundancy:group and redundancy_group"

[julianbrost]

That check would also allow host_id and redundancy_group_id be set at the same time. Should probably be something more like that:

IF(redundancy_group_id IS NULL, host_id IS NULL AND service_id IS NULL, host_id IS NOT NULL)

[yhabteab]

2. redundancy_group -> redundancygroup in all table and column names, see Sync dependencies #889 (comment)

I initially asked Johannes about this and both agreed to keep it as it is, as the effort for renaming on the web side is not worth it compared to a one-line solution on the Go side, i.e. implementing the TableName() method.

[nilmerg]

I'm totally fine with total_children. But redundancygroup because consistency? Web would like to keep naming the respective model RedundancyGroup. I'd also liked to name the Hostgroup model HostGroup, but I was not involved in its naming. I don't see why we should continue this typo here on this new table.

[julianbrost]

Why is it a typo?

[nilmerg]

https://www.dict.cc/?s=usergroup

[julianbrost]

I would consider it a typo if it was was named "hostgruop" or something like that. In that case, naming new things like this for consistency would be truely insane. However, nothing is misspelled here, it's just a question of convention how things are mapped to SQL identifiers.

but I was not involved in its naming

Neither was I, so I don't know the exact motivation for the current names, but the general pattern seems to be that tables are named like the corresponding Icinga 2 object types converted to lowercase with sub-tables (like group members) being named with some _-separated suffix.

So for me, that looks perfectly fine as well, that is, considered in isolation, hostgroup and host_group would be equally valid for me, my preference towards naming the new table redundancygroup only exists because hostgroup was chosen over host_group in the past.

Web would like to keep naming the respective model RedundancyGroup. I'd also liked to name the Hostgroup model HostGroup

I mean that might be nice, but do you really expect that we'd go through the pain of renaming many existing tables any time soon just for cosmetic reasons? And were would you stop? "checkcommand" and "customvar" aren't English words either.

If you insist on the naming for this individual table, I predict that there will be inconsistencies in both the table names (hostgroup + redundancy_group) and the PHP class names (Hostgroup + RedundancyGroup) for the foreseeable future.

In case the PHP class names are that important to you and they are indeed directly tied to the table names, I'd consider relaxing the latter and adding a mechanism similar to that TableName() function in Go on the PHP more constructive: that would introduce no inconsistencies and you could name all your PHP classes just the way you like.

(I really didn't expect that to be such a controversial suggestion...)

[nilmerg]

the general pattern seems to be that tables are named like the corresponding Icinga 2 object types converted to lowercase

Indeed. That's where things went wrong. Icinga 2's class is also camel case. For some reason, someone decided against transforming this to snake case.

I'd consider relaxing the latter and adding a mechanism similar to that TableName() function in Go on the PHP more constructive

There is such a mechanism, but that wasn't implemented for the purpose of having a different naming syntax for class names. I'd have to verify whether this mechanism reliably works this way, where as what you have does already reliably work.

(I really didn't expect that to be such a controversial suggestion...)

I'm actually somewhat annoyed that this even comes up, half a year after I put up the schema suggestion.

[julianbrost]

the general pattern seems to be that tables are named like the corresponding Icinga 2 object types converted to lowercase

Indeed. That's where things went wrong. Icinga 2's class is also camel case. For some reason, someone decided against transforming this to snake case.

I don't see that there's anything inherently wrong with that choice.

(I really didn't expect that to be such a controversial suggestion...)

I'm actually somewhat annoyed that this even comes up, half a year after I put up the schema suggestion.

That's simply something I didn't notice when looking at the schema diff as there's no inconsistency within the diff but only with other parts of the same file. So I actually only noticed the inconsistency when seeing that TableName() implementation and looking into the naming in more detail.

I expected the suggested change to be trivial and I still believe it would be a bad idea to introduce that inconsistency, but it really doesn't feel like that discussion is worth my time. So if you believe this is actually a good idea, I won't stop you, just be prepared for some "told you so" in the future.

[nilmerg]

just be prepared for some "told you so" in the future.

I'll gladly take that risk :)