• Icinga Database essentials

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 4.0


Table of Contents
titleWhy Doctrine ?! Real men use plain SQL!
  • Doctrine offers the possibility to use several database backends (more than ido2db supports at this time) with minimal effort
  • It almost makes fun working with databases if you don't have to worry about how to represent your data in an object form
  • It's not icinga-specific, every module developer can use the ORM
  • Module developers can use 'Soft Relations', i.e. tell doctrine that there is a specific relation to an icinga object without touching the database constraints
    The drawbacks, of course, is that there is a little more memory and processing overhead than when using plain SQL. But keep in mind: Calculation time is cheaper than working time!
titleDoctrine Models and Agavi Models

There are two kinds of models in icinga-web: Doctrine Models and Agavi Models. Both have nothing to do with each other! Doctrine Models define Database Structures, while Agavi Models are models in the MVC concept and contain the applications business logic.
If it's not possible to refer to the kind of model from the context, the model type will be explicitly written out.


The focus of this documentation lies on icinga-web, for advanced queries refer to the official doctrine documentation.

API models

The Api models accessible by icinga are found under app/modules/Api/models. The most generic model is the ApiDataRequestModelApiDataRequestModel only provides basic functionality, which is good for generic requests or creating your own helpers. The other Request classes already provide several helper functions There are several subclasses that provide methods to access services, hosts, hostgroups, etc.

In order to create a request, just create a RequestDescriptor, which selects your database and returns a subclass of Doctrine_Query for you:For example the ApiHostRequestModel allows you to quickly request host information.

Code Block
$model = $this->getContext()->getModel("ApiDataRequestApiHostRequest","Api");
// if no db is given, "icinga" will be used as the default
$r $hosts = $model->createRequestDescriptor>getHostsByCustomVars(array("my database");
$r = $model->createRequestDescriptor("my database");
$r->select("h.display_name,s.display_name")->from("IcingaHosts h")->leftJoin("h.services s");

Request Modifiers

Request modifiers are mainly used for DataStores, but can also be used to quickly add new function to your doctrine query like filtering, sorting, etc.

Code Block

$model LOCATION"=>"DE"));
titleManually switch databases

As we're using the same models for different databases, the DBALManagerModel manages selection of databases

Code Block

    $manager = $this->getContext()->getModel("
database");$query = $model->createRequestDescriptor("my database");$query->select("h.display_name,s.display_name")->from("IcingaHosts h")->leftJoin("h.services s"); $filter = new IcingaStoreFilterModifier(); /* * Create a filter that returns all hosts containing test in display name, and (don't start with exclude or * contain a service "PING") */ $filter1 = new ApiStoreFilter("display_name","LIKE","%test%"); $filter2 = new ApiStoreFilter("display_name","NOT LIKE","Exclude%"); $filter3 = new ApiStoreFilter("s.display_name","=","PING"); $nestedFilterGroup = new ApiStoreFilterGroup("OR",$filter2,$filter3); $filterGroup = new ApiStoreFilterGroup("AND",array($filter1,$nestedFilterGroup)); // Add the filter to the modifier $filter->setFilter($filterGroup); // and execute them on the query $filter->execute($query); // now the query returns only filtered values $query->execute(null,Doctrine_Core::HYDRATE_ARRAY)