Kohana для чайников. Настраиваем базу данных



kohanaВот уже новый год наступил, а я всё никак не соберусь написать про работу с СУБД. Чтобы хоть частично компенсировать этот недостаток напишу про настройку Kohana для работы с базами данных.


Kohana2. Настройка
=======================================

1. Скопировать system/config/database.php в application/config/database.php и прописать там свои настройки MySQL.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
$config['default'] = array
(
	'benchmark'     => TRUE,
	'persistent'    => FALSE,
	'connection'    => array
	(
		'type'     => 'mysql',
		'user'     => 'kohanauser',
		'pass'     => 'secret',
		'host'     => 'localhost',
		'port'     => FALSE,
		'socket'   => FALSE,
		'database' => 'kohana'
	),
	'character_set' => 'utf8',
	'table_prefix'  => '',
	'object'        => TRUE,
	'cache'         => FALSE,
	'escape'        => TRUE
);

2. Собственно, всё готово!! Для быстрой проверки можно написать такой контроллер application/controllers/dbtest:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
<?php defined('SYSPATH') OR die('No direct access allowed.');
 
class Dbtest_Controller extends Controller {
 
        public function __construct()
        {
            parent::__construct();
 
            $this->db = Database::instance();
        }
 
	public function index()
	{
            $query = $this->db->query('select current_date() as date');
            $query->result(false);
            $row=$query->current();
            echo $row['date'];
	}
 
} // Конец контроллера

Kohana3. Настройка
=============================================
1. Нужно в application/bootstrap.php включить модуль database

1
2
3
4
5
6
7
8
9
10
11
12
/**
 * Enable modules. Modules are referenced by a relative or absolute path.
 */
Kohana::modules(array(
	// 'auth'       => MODPATH.'auth',       // Basic authentication
	// 'codebench'  => MODPATH.'codebench',  // Benchmarking tool
	 'database'   => MODPATH.'database',   // Database access
	// 'image'      => MODPATH.'image',      // Image manipulation
	// 'orm'        => MODPATH.'orm',        // Object Relationship Mapping
	// 'pagination' => MODPATH.'pagination', // Paging of results
	// 'userguide'  => MODPATH.'userguide',  // User guide and API documentation
	));

2. Файл modules/database/config/database.php скопировать в application/config/database.php и прописать там настройки MySQL. Например так:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
	'default' => array
	(
		'type'       => 'mysql',
		'connection' => array(
			'hostname'   => 'localhost',
			'username'   => 'kohanauser',
			'password'   => 'secret',
			'persistent' => FALSE,
			'database'   => 'kohana',
		),
		'table_prefix' => '',
		'charset'      => 'utf8',
		'caching'      => FALSE,
		'profiling'    => TRUE,
	)

3. Всё должно работать. Напоследок, контроллер для проверки application/classes/controller/dbtest:

1
2
3
4
5
6
7
8
9
10
11
12
<?php defined('SYSPATH') OR die('No direct access allowed.');
 
class Controller_Dbtest extends Controller {
 
	public function action_index()
	{
        $query = DB::query(Database::SELECT, 'select current_date() as date');
        $row = $query->execute()->current();
        echo $row['date'];
	}
 
} // Конец контроллера

Немного зауми напоследок
========================================
Зачем при настройке мы выполняем копирование настроечных файлов из каталогов системы и модулей в каталог приложения application?

Дело в том, что при правильной инсталляции Kohana все файлы фреймворка находятся за пределами каталога документов. Кроме того, одна инсталляция Kohana может обслуживать несколько сайтов или приложений. А ведь каждое приложение запросто может иметь свои настройки. Особенно настройки СУБД!

Перенося файлы, мы неявно пользуемся тем, что при поиске файлов фреймворк начинает с папок приложения.

Есть другой способ решения проблемы без переноса настроечных файлов в application. Можно задавать специфичные для разных приложений настройки прямо в настроечном файле database.php, там для обеих версий есть возможность указывать инстанс (вариант) вместо default, который в последующем нужно не забыть использовать при обращениях к БД.

Мне первый способ показался более универсальным и естественным.
Впрочем, каждый выбирает по себе.
=)

Посты по теме:

  1. Kohana для чайников. Избавляемся от index.php
  2. Kohana для чайников. Hello world.
  3. Kohana для чайников. Простейший ORM
  4. Kohana для чайников. Инсталляция.
  5. Kohana для чайников. Пользовательские конфиги

Категории Kohana |
автор: altesack / Воскресенье, Январь 03, 2010 / 3 комментов »

3 комментов

    >> Дело в том, что при правильной инсталляции Kohana все файлы фреймворка находятся за пределами каталога документов.

    На самом деле папку Application тоже рекомендуется вынести за web_root. Задача скорее в том, чтобы при обновлении фреймворка не сбрасывались уже настроенные файлы. Ведь папка System содержит файлы самого фреймворка, а в Application все отдано нам на растерзание.

    >> Есть другой способ задавать специфичные для разных приложений настройки. В настроечном файле database.php для обеих версий есть возможность указывать инстанс (вариант) вместо default, который в последующем нужно не забыть использовать при обращениях к БД.

    Ну, если хранить настройки в Application, то разным приложениям они не будут доступны, ведь у каждого из них своя папка Application. В данном случае разные инстансы нужны для использования в рамках одного приложения. Например, одна база использует префиксы для таблиц, а другая нет. Или для различного вида СУБД.

    biakaveron пишет:

    Задача скорее в том, чтобы при обновлении фреймворка не сбрасывались уже настроенные файлы.

    Кстати да, я об этом не подумал!

    На самом деле папку Application тоже рекомендуется вынести за web_root.

    Согласен.В посте об инсталляции я так и советовал делать :)

    Ну, если хранить настройки в Application, то разным приложениям они не будут доступны, ведь у каждого из них своя папка Application.

    Хм.. Извиняюсь на несколько косноязычные тексты, немного изменил текст. Я там имел в виду “если не переносить”.

    В данном случае разные инстансы нужны для использования в рамках одного приложения. Например, одна база использует префиксы для таблиц, а другая нет. Или для различного вида СУБД.

    Опа… Об этом я тоже как-то не подумал.
    Правда я не сталкивался с такими случаями, чтобы одно приложение нуждалось в разных настройках БД.

    Было бы неплохо снабдить листинг конфига комментариями

Ответить