diff --git a/source/Tutorials/understandingOmeka_Record_AbstractRecord.rst b/source/Tutorials/understandingOmeka_Record_AbstractRecord.rst index 0f544192..e26bdb7a 100644 --- a/source/Tutorials/understandingOmeka_Record_AbstractRecord.rst +++ b/source/Tutorials/understandingOmeka_Record_AbstractRecord.rst @@ -4,43 +4,73 @@ Understanding Omeka_Record_AbstractRecord ######################################### +:php:class:`Omeka_Record_AbstractRecord` is the heart of the ORM for Omeka. It is an abtract class that is extended to create the models for +Omeka and its plugins. Each class extending ``Omeka_Record_AbstractRecord`` corresponds to a database table, with each row representing an +individual record. Table columns correspond to public properties of the class. -:php:class:`Omeka_Plugin_AbstractRecord` is extended to create the models for Omeka and its plugins. It corresponds to a database table, with each row representing an individual record. Table columns correspond to public properties of the class. +In plugins, it's best practice to include the name of the plugin at the beginning of each model name, to avoid any potential conflicts with +models from the core or other plugins. + +Classes extending ``Omeka_Record_AbstractRecord`` are placed in the ``models`` folder of a plugin (or ``application/models`` in the core). +You can choose to keep the model classes all directly under the ``models`` folder or organize them into subfolders. Omeka will work with +either organizational style, but as with all other class files, additional levels of the folder structure must have corresponding underscores +in the class name. For example, a model named ``MyPluginThing`` would be located at ``/models/MyPluginThing.php``, while one named +``MyPlugin_Thing`` would be located at ``MyPluginThing``) from the DB object will return the table name for that model, correctly prepended with the user's +configured database prefix. This is the preferred way to get the table name when needed for SQL queries (like a ``CREATE TABLE`` query). -For example this code in a plugin's `install` hook will create the table for the above model. +To create the tables in the database table for a plugin, use the :doc:`install hook `. The table must contain +a column for each public property of the model, as well as an auto-incrementing ``id`` column as the primary key. For example, this code +in a plugin would create a table for the above model: .. code-block:: php + protected $_hooks = array('install' /* ... */); + + /* ... */ + public function hookInstall() { $db = $this->_db; $sql = " - CREATE TABLE IF NOT EXISTS `$db->MyThing` ( - `id` int(10) unsigned NOT NULL AUTO_INCREMENT, - `text` text NOT NULL, - . . . - ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci"; + CREATE TABLE IF NOT EXISTS `$db->MyPluginThing` ( + `id` int(10) unsigned NOT NULL AUTO_INCREMENT PRIMARY KEY, + `text` text NOT NULL + ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci"; $db->query($sql); } +Other features like additional indexes besides the primary key would be specified in the CREATE TABLE statement when necessary. + +Plugins that create tables should drop them in their :doc:`uninstall hook `. + +******************** +Events and callbacks +******************** + The abstract record contains callback functions creating, reading, updating, and deleting records, both before and after those actions. These are helpful if any automatic processing should be done during those operations. -For example, to append a message to text as the record is saved, override the `beforeSave()` callback. +For example, to append to the ``text`` column before the record is saved, override the ``beforeSave()`` callback. .. code-block:: php