| 5 | | Schema evolution is the function of updating an existing Django generated database schema to a newer/modified version based upon a newer/modified set of Django models. |
| 6 | | |
| 7 | | === Limitations === |
| 8 | | |
| 9 | | I feel it important to note that is an automated implementation designed to handle schema ''evolution'', not ''revolution''. No tool, other than storing DBA written SQL scripts and auto-applying them via schema versioning or DB fingerprinting (which is a trivial solution - I have a Java implementation if anyone wants it), can handle the full scope of possible database changes. Once you accept this fact, the following becomes self-evident: |
| 10 | | |
| 11 | | * There is a trade off between ease of use and the scope of coverable problems. |
| 12 | | |
| 13 | | Combine that with: |
| 14 | | |
| 15 | | * The vast majority of database changes are minor, evolutionary tweaks. (*) |
| 16 | | * Very few people are DBAs. |
| 17 | | |
| 18 | | And I believe the ideal solution is in easing the life of common Django developer, not in appeasing the DBA's or power-developer's desire for an all-in-one-comprehensive solution. Massive schema changes (w/ data retention) are always going to require someone with database skill, but we can empower the people to do the simple things for themselves. |
| 19 | | |
| 20 | | (*) By this I mean adding/removing/renaming tables and adding/removing/renaming/changing-attributes-of columns. |
| | 5 | Schema evolution is the function of updating an existing Django generated database schema to a newer/modified version based upon a newer/modified set of Django models, and/or a set of developer written upgrade scripts. |
| | 6 | |
| | 7 | It's important to note that different developers wish to approach schema evolution in different ways. As detailed in the original SchemaEvolution document (and elsewhere), there are four basic categories of developers: |
| | 8 | |
| | 9 | 1. users who trust introspection and never want to touch/see SQL (Malcolm) |
| | 10 | 1. users who mostly trust introspection but want the option of auto-applied upgrades for specific situations (Wash) |
| | 11 | 1. users who use introspection-generated SQL, but don't trust it (they want it generated at development and stored for use in production - Kaylee) |
| | 12 | 1. users who hate introspection and just want auto-application of their own scripts (Zoe) |
| | 13 | |
| | 14 | who wish to perform different combinations of the two basic subtasks of schema evolution: |
| | 15 | |
| | 16 | 1. generation of SQL via magical introspection |
| | 17 | 1. storage and auto-application of upgrade SQL |
| | 18 | |
| | 19 | This implementation of schema evolution should satisfy all four groups, while keeping the complexities of the parts you don't use out of sight. Scroll down to the usage sections to see examples of how each developer would approach their jobs. |
| 53 | | == How To Use |
| 54 | | |
| 55 | | For the most part, schema evolution is designed to be automagic via introspection. Make changes to your models, run syncdb, and you're done. But like all schema changes, it's wise to preview what is going to be run. To do this, run the following: |
| 56 | | |
| 57 | | {{{ |
| 58 | | |
| | 52 | == How To Use: Malcolm == |
| | 53 | |
| | 54 | For the most part, schema evolution can be performed via introspection, as long as you're not doing anything too radical. If you have an established application the ''vast'' majority of changes are either additions or renames (either tables or columns). Or if you're new to SQL, introspection keeps things very simple for you. To use schema evolution as Malcolm just make changes to your models, run syncdb, and you're done. But like all schema changes, it's wise to preview what is going to be run. To do this, run the following: |
| | 55 | |
| | 56 | {{{ |
| | 57 | $ ./manage sqlevolve app_name |
| 89 | | For further examples... |
| 90 | | |
| 91 | | == Usage Examples == |
| 92 | | |
| 93 | | The following documentation will take you through several common model changes and show you how Django's schema evolution handles them. Each example provides the pre and post model source code, as well as the SQL output. |
| | 88 | And after time you make a series of changes, run sqlevolve or syncdb and your schema changes will be either shown to you or applied for you. |
| | 89 | |
| | 90 | For further examples, scroll down to the Introspection Examples section. |
| | 91 | |
| | 92 | == How To Use: Wash == |
| | 93 | |
| | 94 | Note that most Malcolm developers (likely new developers) will eventually run up against a limitation inherent in introspection. They love their incredibly intuitive tool but it can't do everything. But they don't want to give it up, because it's a great 90% solution. If only they can add a simple script without having to throw away all the convenient candy, past or future. |
| | 95 | |
| | 96 | All Wash has to do is store a little bit of extra metadata. Namely two things: |
| | 97 | |
| | 98 | 1. a fingerprint of the known schema |
| | 99 | 1. an sql script |
| | 100 | |
| | 101 | in the file 'app_name/schema_evolution.py'. (conveniently next to models.py) |
| | 102 | |
| | 103 | This module looks as follows: |
| | 104 | |
| | 105 | {{{ |
| | 106 | # list of all known schema fingerprints, in order |
| | 107 | fingerprints = [ |
| | 108 | 'fv1:1742830097', |
| | 109 | 'fv1:907953071', |
| | 110 | # add future fingerprints here |
| | 111 | ] |
| | 112 | |
| | 113 | # all of your evolution scripts, mapping the from_version and to_version |
| | 114 | # to a list if sql commands |
| | 115 | evolutions = { |
| | 116 | # ('from_fingerprint','to_fingerprint'): ['-- some sql'], |
| | 117 | ('fv1:1742830097','fv1:907953071'): [ |
| | 118 | '-- some list of sql statements, constituting an upgrade', |
| | 119 | '-- some list of sql statements, constituting an upgrade', |
| | 120 | ], |
| | 121 | } |
| | 122 | }}} |
| | 123 | |
| | 124 | To create this file, he would first fingerprint his schema with the following command: |
| | 125 | |
| | 126 | {{{ |
| | 127 | $ ./manage sqlfingerprint app_name |
| | 128 | Notice: Current schema fingerprint for 'app_name' is 'fv1:1742830097' (unrecognized) |
| | 129 | }}} |
| | 130 | |
| | 131 | He would add this fingerprint to the end of the 'fingerprints' list in the schema_evolution module, and it would become an automatically recognized schema, ripe for the upgrade. And then he would write an upgrade script, placing it in the 'evolutions' dictionary object, mapped against the current fingerprint and some fake/temporary fingerprint ('fv1:xxxxxxxx'). Finally, he would run his script (either manually or via syncdb), re-fingerprint and save it in both the fingerprints list and the 'to_fingerprint' part of the mapping. |
| | 132 | |
| | 133 | Later, when he runs sqlevolve (or syncdb) against his production database, sqlevolve will detect his current schema and attempt an upgrade using the upgrade script, and then verify it. If it succeeds, will continue applying all available upgrade scripts until one either fails or it reaches the latest database schema version. (more technically, syncdb will recursively apply all available scripts...sqlevolve since it simply prints to the console, only prints the next available script) |
| | 134 | |
| | 135 | '''Note:''' Manually defined upgrade scripts always are prioritized over introspected scripts. And introspected scripts are never applied recursively. |
| | 136 | |
| | 137 | This way Wash can continue using introspections for the majority of his tasks, only stopping to define fingerprints/scripts on those rare occasions he needs them. |
| | 138 | |
| | 139 | == How To Use: Kaylee == |
| | 140 | |
| | 141 | Kaylee, like Wash and Malcolm, likes the time-saving features of automatic introspection, but likes much more control over deployments to "her baby". So she typically still uses introspection during development, but never in production. What she does is instead of saving the occasional "hard" migration scripts like Wash, she saves them all. This builds a neat chain of upgrades in her schema_evolution module which are then applied in series. Additionally, she likes the ability to automatically back out changes as well, so she stores revert scripts (also usually automatically generated at development) in the same module. |
| | 142 | |
| | 143 | == How To Use: Zoe == |
| | 144 | |
| | 145 | Zoe simply doesn't like the whole idea of introspection. She's an expert SQL swinger and never wants to see it generated for her (much less have those ugly "aka" fields buggering up her otherwise pristine models. She simply writes her own SQL scripts and stores them all in her schema_evolution module. |
| | 146 | |
| | 147 | == Introspection Examples == |
| | 148 | |
| | 149 | The following documentation will take you through several common model changes and show you how Django's schema evolution introspection handles them. Each example provides the pre and post model source code, as well as the SQL output. |