Symfony Project sfservermon - Post 1 - Step 1 Entities

As an example Symfony 2 project, this series of blog posts details the migration of an existing php website project to the Symfony 2 framework.
The project the subject of this series of posts is php server mon - see Php Server Monitor on sourceforge.
Php Server Monitor is an monitoring system developed by Pep, it was chose for this project as an example because:

• The application developed by Pep is well written and great at what is does.
• It is a useful example - different from other examples - but not too complex.
• It provides a useful example of migrating an existing application to Symphony.

Goal:

The purpose of migrating it to Symfony 2 is not to improve the site or the code as that is not needed but to document migrating an existing project to Symfony and then extending it to support mobile phone browsers through JQuery mobile.

All existing functionality will be maintained, this includes:

• monitoring hosts (by ping), websites (by a http get) and services (by a telnet connection).
• logging the results.
• providing alerts - webpage display, emails and alerts.
• database schema is unchanged, so the new project could be a direct upgrade of the existing application.

The initial implementation will support English, however it will then be extended with language support - as the existing project does.

Later in the series I do have a couple of posts about some added features.

Also, the code will be edited as per the bundle best practice guidelines.

Step 1 Creation of ORM files and Entities.

The existing schemas has the following tables:

• monitor_config - primary key (config_id) - application configuration data.
• monitor_servers - primary key (server_id) - list of monitoring targets (servers).
• monitor_log - primary key (log_id) - has many to one relation to monitor_servers.
• monitor_users - primary key (user_id) - has comma seperated list of servers to be alerted.

This cookbook article was followed to developed the orm files, then some edits were required:

1a Mysql Enum support.

This post was followed to add the following enum:

  `type` enum('service','website','host') NOT NULL DEFAULT 'service' COMMENT '(DC2Type:enumservermonitor)',

1b. Keyword Column support.

The monitor_config table has the SQL:

CREATE TABLE `monitor_config` (
  `config_id` int(11) NOT NULL AUTO_INCREMENT,
  `key` varchar(255) COLLATE utf8_unicode_ci NOT NULL,
  `value` varchar(255) COLLATE utf8_unicode_ci NOT NULL,
  PRIMARY KEY (`config_id`)
) ENGINE=InnoDB AUTO_INCREMENT=18 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;


The key column is a keyword and needs to be escaped.
Add this statement to the orm file as generated above:

    key:
      column: `key`
      type: string
      length: 255
      fixed: false
      nullable: false
    value:
      column: `value`
      type: string
      length: 255
      fixed: false

The same was done for the value column, though not necessary.

1c. Renaming Mapped Column Names.

The primary key fields are non standard, examples are
Servers: server_id, Users: user_id rather than id.
You can renamed the field names in the yml files which will keep the database column name unchanged, but rename the Entity field to id.
From:

JMPR\ServerMonBundle\Entity\MonitorConfig:
  type: entity
  table: monitor_config
  fields:
    configId:
      id: true
      type: integer
      unsigned: false
      nullable: false
      column: config_id
      generator:
        strategy: IDENTITY

To:

JMPR\ServerMonBundle\Entity\MonitorConfig:
  type: entity
  table: monitor_config
  fields:
    id:
      id: true
      type: integer
      unsigned: false
      nullable: false
      column: config_id
      generator:
        strategy: IDENTITY

Note the column field (config_id)

1d. Relations support.

The orm generation doesn't include support for the mapping (relations between the tables)
These where added to the orm files:


JMPR\ServerMonBundle\Entity\MonitorServers:
...
  oneToMany:
    log:
      targetEntity: MonitorLog
      mappedBy: log

Monitor log:

  manyToOne:

    server:

       targetEntity: MonitorServers

       inversedBy: server

       joinColumn:

         name: server_id

         referencedColumnName: server_id

As no standard primary key fields are used (log_id rather than id in monitor_log), the join column must be specified.

The next post discusses loading test data.