Raptor and Version Control

Question

Here are some discussion points for use of Raptor with version control.
Assumptions/Terminology.
Roles:
Developer, Tester, Production DBA.
Each developer has their own database or schema to work with.
Database code is PL/SQL and DDL
Client code is everything else including sql scripts.
VC stands for generic version control. I may slip into CVS speak, but ideally this is product neutral.
Scenario 1: New developer on existing project.
1 Check out sources
Obviously need to define a VC repository connection in Raptor
Probably also need to define filesystem directory to check out to. Conceivably raptor could do this under the covers but if the source code is a mixture of database code and client code this isn't possible.
2 Run sources against database to create schema objects
This would probably be a manual job within raptor but a nice feature would be a tool to work out the dependencies and run everything in the right order.
3 Edit-save-compile-edit objects in the database
At this stage the database code is out of sync with the filesystem and the VC. Since the definitive version is in VC the filesystem is irrelevant so it would make sense to save the object back to the filesystem when you click the save/compile button.
If VC isn't active this is obviously a bad idea since the filesystem version is the backup.
4 Create new object in database.
The new object needs to be immediately saved to the filesystem and added to VC(but not committed). The create dialog should ask for a filename as well as object name.
5 Commit changes to VC
What gets committed? All the database code in the schema of the current connection? All the database code which is known to CVS (which should include new ones created at step 4)? What about client code? Is there a need for a project to which objects can be added manually or automatically.
There may be clashes between this developer's changes and anothers.
Need to be able to compare current database with current cvs and merge in changes before commiting. The merged changes need to be immediately applied to the database.
6 Whoops forgot something, edit object on filesystem but don't check in.
7 Next day, try to edit same object in the database.
We now have a 3-way discrepancy between vc, filesystem and database. Raptor needs to allow diff/merge between database and filesystem as well as between database and VC.
Scenario 2: New Project
1 Developer creates some database code
edit-save-compile is entirely within the database at this stage and no VC is involved. At some point the developer has to define a vc repository and directory. Raptor needs to be able to create a new repository or module (cvs import for example) either at this stage or the first time code is saved.
There could be an option to make VC compulsory so that whenever a developer creates an object, the relevant VC actions are taken.
2 This scenario merges into scenario 1.
Scenario 3: Tester begins new testing cycle
Scenario 4: DBA implements new code in production database.
1     User checks out latest code from CVS
2     User runs code against database to create schema objects.
This is very straight forward. I am not even sure that this should involve raptor, it should all be done by scripts in sqlplus. The one raptor involvement could be reconcilation of the objects in the test database with the VC repository.
A few other thoughts.
I haven't thought about multi-schema development, ie making changes to more than one schema at a time. Should a VC repository be associated with a particular connection?
I haven't thought about managing 'create table' vs 'alter table'. A tool which generated an alter table from the different between db and vc or between 2 vc revisions would be useful.
All checkout/export/diff actions should be against labels/tags/branches as well as the tip.
Filenames and formats.
There should be preferences to allow the user to specify file extensions and other naming conventions (eg upper/lower case). I use the following for ddl files
table_name.tbl -- create table
table_name.con -- constraints for table
table_name.idx -- indexes for table
view_name.vue
sequence_name.seq
Table DDL
Currently table ddl as generated from raptor includes storage details. Not all of this is relevant in the development process and could cause spurious differences in version control.
I also like my constrains in a separate file from the table ddl.
PL/SQL Templates
The ability to define basic package and procedure templates with VC keywords etc in place. New | Procedure etc would use these templates
Message was edited by:
smitjb

Answer 1

Thanks for the detailed use cases. We can use this message to track Version control feature requests.
We do want to provide this support in future releases.
Donal