1 |
Benjamin Blazke wrote: |
2 |
> |
3 |
> --- kashani <kashani-list@××××××××.net> wrote: |
4 |
> |
5 |
>> The tool you're looking for is called a DBA. :-) |
6 |
> |
7 |
> I see. So it's up to QA to test extensively and up to |
8 |
> the DBA to recover from a disaster. |
9 |
> |
10 |
> I hoped there would be a more automated solution but |
11 |
> it seems that it's not really doable. Thanks for such |
12 |
> a quick answer ;-) |
13 |
|
14 |
That's pretty much the way we've been doing it, but if there is a |
15 |
better way I'd like to hear it too as I'm a poor imitation of a DBA. |
16 |
However I don't see any easy solutions for combined application, data, |
17 |
schema change rollbacks especially when changes to one cause |
18 |
dependencies in others. |
19 |
|
20 |
As an illustration you change u_user.login_name to varchar(64) from |
21 |
varchar(32). Users start creating longer users names. A few hours later |
22 |
you find some problems in how your application handles longer names. If |
23 |
you needed to rollback the alter table command is easy, but some of your |
24 |
data would now be invalid. Rather than rollback the easier fix is to |
25 |
update the application and hopefully the change is a single file update. |
26 |
|
27 |
I still think there are cases when you could rollback, but they'd have |
28 |
to be so simple that having a tool to generate the sql would be overkill. |
29 |
|
30 |
Ramin |
31 |
-- |
32 |
gentoo-user@g.o mailing list |