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

Re: Database Development w/ SVN

From: Daniel Becroft <djcbecroft_at_gmail.com>
Date: Fri, 13 Nov 2009 08:20:31 +1000

On Thu, Nov 12, 2009 at 7:19 PM, Felix Gilcher
<felix.gilcher_at_bitextender.com> wrote:
>
> On Nov 12, 2009, at 4:12 AM, Thomas Harold wrote:
>
>> On 11/10/2009 3:44 PM, Daniel Becroft wrote:
>>> Hi all,
>>>
>>> This is more of a best or general practice question than anything
>>> else. How do you manage/version external database schema and static
>>> data changes in an SVN environment?
>>
>> Small static tables could be dumped to a .sql type plain text file
>> (which is usually just a big SQL INSERT statement) and kept in SVN.
>> Figure one file per table.
>>
>> You could probably put the create table queries in .sql files as well.
>
> I usually keep a set of scripts that does the required changes in svn. This seems to be a pretty standard practice, you might want to have a look at activerecord migrations (ruby on rails) or doctrine migrations (php) for an example. Basically it's a set of sequentially numbered scripts that each update the database from the previous version to the next version, doing all table changes and data manipulation that are required. Usually there's a table in the database that somehow stores the current version. Migrations may incorporate the ability to revert the changes if required. There's some communication involved if multiple persons are changing the database, the solution to that really depends on your workflow.

Thanks, Felix and Thomas.

I realise I forgot to mention that we don't use an SQL database - we
are writing against an OpenEdge database. Unfortunately, this means
that schema deltas and data changes are in separate files (deltas are
in .df and changes are in standard .p programs). This is purely an
implementation issue, though.

We are leaning towards creating a custom version of the ActiveRecord
migrations concept, although due to performance issues when applying
schema, we might run all deltas, then all data changes. Our upgrade
path is fairly linear (ie if the system is on 1.1.1, then the client
must run 1.2.0 upgrade before any 1.2.x patches or running the 1.3.0
upgrade, etc).

Cheers,
Daniel B.

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2417287

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-11-12 23:21:52 CET

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.