[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Managing SQL in the repository (was: Organization Advise)

From: Gary Affonso <glists_at_greywether.com>
Date: 2004-05-29 20:07:48 CEST

On 5/28/04 2:42 PM, "Brad Rhoads" <brhoads@zethcon.com> wrote:

> How do we
> deal with the SQL as it is functionally related to other parts of the
> system?

We're dealing this this one, too, right now and our solution for Store
Procedures is this:

1) We require that our developers "script" their schema-related (not data
related) changes to the script. In short, they're not allowed to simply
open up an sproc-editor and make a quick change. They have to put the
change in a "create sproc" script.

We keep these scripts in a directory on our repository.

2) Ensure that the "script" is written such that it drops the old resource
before adding the new one. In short we disallow the use of alter statements
for sprocs.

3) We require that there is one file for every sproc on the database.

And then we just manage those scripts as if they were standard code.

This gets us all the normal repository abilities (snapshots, branches,
merges, diffs) on sproc-related SQL resources.

Tables are trickier because we can't "drop" the old table before adding new
one (the data would go away).  This means we're forced to use alter
statements to make table-related mods (instead of the drop/replace scheme we
use for sprocs).
And that means that a table's given state is a combination of the original
create-scripts and a handful of alter scripts that have come after its
original creation.  Which means no ability to easily diff different table
So for table-related DDL, I'm still not sure how we'll be handling it, I'd
love to hear some suggestions.
- Gary
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat May 29 20:08:33 2004

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.