| 98 | |
| 99 | == Current Design == |
| 100 | |
| 101 | (taken from source:sandbox/multirepos/trac/db_default.py@8081) |
| 102 | {{{ |
| 103 | #!python |
| 104 | # Version control cache |
| 105 | Table('repository', key=('id', 'name'))[ |
| 106 | Column('id'), |
| 107 | Column('name'), |
| 108 | Column('value')], |
| 109 | Table('revision', key=('repos', 'rev'))[ |
| 110 | Column('repos'), |
| 111 | Column('rev'), |
| 112 | Column('time', type='int'), |
| 113 | Column('author'), |
| 114 | Column('message'), |
| 115 | Index(['repos', 'time'])], |
| 116 | Table('node_change', key=('repos', 'rev', 'path', 'change_type'))[ |
| 117 | Column('repos'), |
| 118 | Column('rev'), |
| 119 | Column('path'), |
| 120 | Column('node_type', size=1), |
| 121 | Column('change_type', size=1), |
| 122 | Column('base_path'), |
| 123 | Column('base_rev'), |
| 124 | Index(['repos', 'rev'])], |
| 125 | }}} |
| 126 | |
| 127 | === Discussion === |
| 128 | |
| 129 | From IRC, lelit (author of the TracDarcs plugin) suggested that using a ''surrogate id primary key'' for the repository would be more adequate for his use case, as he's re-using the `CachedRepository` and extending it with extra information, that extra information being stored in additional tables (e.g. for binding an artificial integer revision id to the corresponding Darcs hash and Darcs name): when renaming a repository, he would have to update his tables as well. There's currently no extension point for reacting to such changes, but the idea was that if we were using an unique integer id for the repository, there would be no need to update anything after a simple renaming (i.e. the repository name would be just another repository property). |
| 130 | |
| 131 | (short IRC transcription before going to bed, feel free to fix/clarify Lele ;-) ) |