IWETHEY v. 0.3.0 | TODO
1,095 registered users | 1 active user | 0 LpH | Statistics
Login | Create New User
IWETHEY Banner

Welcome to IWETHEY!

New Er, what headaches?
We have a million lines of stored procedures, deployed nightly into 5 different environments. What headaches are you referring to?
Regards,

-scott anderson

"Welcome to Rivendell, Mr. Anderson..."
New Depends how you're set up
Where I've worked, code is stored in CVS, and then rollouts happen by specific releases getting copied to production. (At my current job, followed by restarting Apache.) Rollbacks can happen by copying the old release out. (At my current job, machines are taken out of the load balancer, restarted, put back into the pool and then others are taken out.)

This can happen while the system is live and under use. In fact sometimes you want it to happen under moderate use so that you can monitor for potential issues right away in the error logs. (A developer's unit tests tend to reflect the same assumptions that go into that developer's code. Real users may use the system in ways that violate those assumptions...)

This is a very simple way to work, and it seems to work well. But synchronizing that with database state is harder, it is nontrivial just to verify that all views and stored procedures in databases match what is in CVS. And if you have multiple developers connecting to the same database, you can't have each one with their own versions of things.

The most reasonable solution for a small group seems to be to ensure that view and stored procedure changes are always forwards compatible - the new database stuff works with old code. This lets database changes be rolled out ahead of time. Which is doable, just a bit of a PITA.

Cheers,
Ben
To deny the indirect purchaser, who in this case is the ultimate purchaser, the right to seek relief from unlawful conduct, would essentially remove the word consumer from the Consumer Protection Act
- [link|http://www.techworld.com/opsys/news/index.cfm?NewsID=1246&Page=1&pagePos=20|Nebraska Supreme Court]
New Re: Depends how you're set up
I don't see how this is any more of a headache than making sure that table changes are all synchronized with the external code. If you change a table, and then change the wrapping stored procedure, this has to be matched with the external code, natch. If you change a table, and the wrapping is in the external code, you still have to match the changes. No real difference there that I can see.

We do things a bit differently here: 4 environments, 3 of which (test, qa, prod) can be seen by clients. Every night dev, test and qa are rebuilt out of the source code control system using an automated SQL loading tool that ensures that the database is consistent. Since clients are in qa all day long, we catch unintended aspects of the system like you mentioned. Production roll-outs can therefore take the whole system down at once, replace everything, then come back up without inconsistencies. We don't have an absolute requirement for 24x7 operation; I assume we would have a mirror system to update, then flip a switch when we needed to convert, if that were the case.

And if you have multiple developers connecting to the same database, you can't have each one with their own versions of things.
Seems to me this would be an argument for putting the wrappers in stored procedures. :-)
Regards,

-scott anderson

"Welcome to Rivendell, Mr. Anderson..."
New More moving parts
I don't see how this is any more of a headache than making sure that table changes are all synchronized with the external code. If you change a table, and then change the wrapping stored procedure, this has to be matched with the external code, natch. If you change a table, and the wrapping is in the external code, you still have to match the changes. No real difference there that I can see.

Option 1: Change the table. Then the view. Then rollout code.

Option 2: Change the table. Then the view. Then each stored procedure. Then rollout code.

Both options add complexity. But the second one adds somewhat more because you have more pieces that got changed.
We do things a bit differently here: 4 environments, 3 of which (test, qa, prod) can be seen by clients. Every night dev, test and qa are rebuilt out of the source code control system using an automated SQL loading tool that ensures that the database is consistent. Since clients are in qa all day long, we catch unintended aspects of the system like you mentioned. Production roll-outs can therefore take the whole system down at once, replace everything, then come back up without inconsistencies. We don't have an absolute requirement for 24x7 operation; I assume we would have a mirror system to update, then flip a switch when we needed to convert, if that were the case.

Our requirement for 24x7 is somewhat soft. We sometimes take down the system for an hour or two for database maintainance tasks that are easier done offline.

However we don't like scheduling any more outages than we need, since the system is always doing something. During the day (we have long days since people are in different timezones accessing us) we have people on the website. At night the website is quieter, but we send emails out.

As for simulating usage, given what we do, it is hard for us to come up with a realistic mix in QA that matches the variety of random cases that thousands of people using the site provide.
And if you have multiple developers connecting to the same database, you can't have each one with their own versions of things.
Seems to me this would be an argument for putting the wrappers in stored procedures. :-)

We're talking past each other. What I'm saying is that stored procedures prevent people from keeping their private development completely private. Which is a strike against stored procedures.

I think that you're saying that if you can't keep development environments private, then that is an argument for pushing people to not even maintain the illusion of trying to do so. Which logic, taken to its logical conclusion, suggests that all developers should be working on a shared server, editing a shared source-code tree. Which is an obviously absurd conclusion that I hope you don't advocate.

It may well be that what I think you're saying is not what you meant. In which case I'd appreciate clarification.

Cheers,
Ben
To deny the indirect purchaser, who in this case is the ultimate purchaser, the right to seek relief from unlawful conduct, would essentially remove the word consumer from the Consumer Protection Act
- [link|http://www.techworld.com/opsys/news/index.cfm?NewsID=1246&Page=1&pagePos=20|Nebraska Supreme Court]
     Discussion topic: data-aware controls on forms - (admin) - (31)
         How active? Context? - (ben_tilly) - (3)
             Re: How active? Context? - (admin) - (2)
                 Are you really asking why Access is a bad idea? -NT - (ben_tilly) - (1)
                     Whoops. - (admin)
         Bad idea. - (mmoffitt) - (18)
             Implementation vs effect - (ben_tilly) - (17)
                 Consider what goes on in most such setups. - (mmoffitt) - (12)
                     Don't be sure about the surely - (ben_tilly) - (11)
                         Re: Don't be sure about the surely - (admin) - (4)
                             That I agree with - (ben_tilly) - (3)
                                 Why more? - (admin) - (2)
                                     Duplication of information - (ben_tilly) - (1)
                                         Must depend on what you're doing. - (admin)
                         I can't add much to what Scott said. - (mmoffitt) - (5)
                             Then see my response to Scott - (ben_tilly) - (4)
                                 I did. And how? - (mmoffitt) - (3)
                                     Ah, good point - (ben_tilly) - (2)
                                         Problem is rollback - (drewk) - (1)
                                             That's only an argument for a wrapper - (ben_tilly)
                 Er, what headaches? - (admin) - (3)
                     Depends how you're set up - (ben_tilly) - (2)
                         Re: Depends how you're set up - (admin) - (1)
                             More moving parts - (ben_tilly)
         always thought that all forms should be a view of the table - (boxley)
         Depends on the kind of data - (ChrisR) - (2)
             Mostly agree - (ben_tilly) - (1)
                 Love 'impedance mismatch' ! - (Ashton)
         You didn't specify stateful or stateless system - (drewk) - (2)
             Stateful. - (admin) - (1)
                 Then the issue is multi-column constraints - (drewk)
         Neat idea, but marginal in practice - (JayMehaffey)

I couldn't find my socks this morning, so I dialed information.
59 ms