User Tools

Site Tools


devel:update-database-schema

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
devel:update-database-schema [2012/09/14 13:17]
miconda
devel:update-database-schema [2015/12/04 09:18] (current)
smititelu
Line 23: Line 23:
 </code> </code>
  
-This command generates the SQL or control files to be used by kamdbctl tool when creating the database structure. It requires the tool **xsltproc** to process the XML files, tool which is also needed for generation of the readme files.+This command generates the SQL or control files to be used by kamdbctl tool when creating the database structure. It requires the tool **xsltproc** to process the XML files, tool which is also needed for generation of the readme files. The sql scripts will be placed in subfolders of 'utils/kamctl/'
  
 Changing the structure of an existing database table requires only the above steps. Adding a new table requires as well: Changing the structure of an existing database table requires only the above steps. Adding a new table requires as well:
Line 29: Line 29:
   * adding the table to kamctl and kamdbctl tools for creation   * adding the table to kamctl and kamdbctl tools for creation
  
-For example, the group of the tables used by module domain is specified in file:+For example, the group of the tables used by module domain, domain and domain_attrs, is specified in file:
  
 <code> <code>
Line 35: Line 35:
 </code> </code>
  
-It includes references to two tables: domain and domain_attrs.+To generate the documentation of the existing kamailio-db-devel tables: 
 +<code> 
 +cd lib/srdb1/schema; make docbook-xml 
 +cd doc/databases/kamailio; make html 
 +firefox tables.html 
 +</code>
  
-If you add a new table, you must add the new files related to it to GIT repository, before committing the changes. +If you add a new table, you must add the new files related to it to GIT repository, before committing the changes. It is recommended to split the commit in two parts, because they affect different components:
- +
-It is recommended to split the commit in two parts, because they affect different components:+
   * one for the XML files (they are part of internal library srdb1)   * one for the XML files (they are part of internal library srdb1)
   * one for DB creation scripts (they are part of kamctl tool)   * one for DB creation scripts (they are part of kamctl tool)
  
 This brings the benefit of easy backporting, because the commit to xml file is unlikely to create conflicts, changing one file in a group of lines related to same column, so it can be cherry-picked alone. Commits to database creation scripts affects many files and can result in conflicts if new columns were added meanwhile to the development version to that table. This brings the benefit of easy backporting, because the commit to xml file is unlikely to create conflicts, changing one file in a group of lines related to same column, so it can be cherry-picked alone. Commits to database creation scripts affects many files and can result in conflicts if new columns were added meanwhile to the development version to that table.
 +
  
 If there is a fix that has to be backported, always do it to master branch and then cherry-pick it in the stable branches. With split commits, the typical backport procedure is: If there is a fix that has to be backported, always do it to master branch and then cherry-pick it in the stable branches. With split commits, the typical backport procedure is:
devel/update-database-schema.1347621422.txt.gz · Last modified: 2012/09/14 13:17 by miconda