|
We do test, on 4 PCs. Last week patched them (one after the other) and started the automated tests. Next day an email with the differences, if any.
With this update its goanna take a week before we know the result on 4 PC’s
We make small well defined changes, making sure we stay in control. The Windows.Old directory after the “Fall update” is nearly 30 GB. It really makes me nervous. Who is in control?
I’m pretty sure you have something with parts originating our company. Consider those made in a controlled environment, with well tested in-house made software making sure nothing is wrong with the quality.
|
|
|
|
|
Peter Sentveld wrote: It really makes me nervous. Who is in control?
Dunno; but the changes were pleasant enough to make me try Ubuntu.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
I had a thought. (I know: run, screaming, and hide your kids...)
I often have to write code to deal with data migrations. We add a column to a database and we need to briefly have the code run on staging and production, running against the same database. So I add code like "if column exists, load column value". After the deploy is completed we remove the "if column exists" and redeploy.
Has anyone ever heard of a system or language or framework that provides the means to have code self-destruct after a certain date? Does this even make sense? Am I few coffees short of a barista today?
It just seemed...intriguing.
cheers
Chris Maunder
|
|
|
|
|
Isn't the standard pattern to add a nullable column, then once the data's all there, make it non-nullable?
|
|
|
|
|
You've just sent every DBA in the room screaming and clawing at their eyeballs 
The situation is that the new code expects a column; the old version doesn't. Usually you can just update the database without the old code caring, then update the code and the new code picks up the new column.
What if you can't run the migration until after you deploy the code because part of the migration will screw up, right royally, the old code? (The specific situation I have is a field being renamed then a new field being added with the previous name. Bad naming choices years ago...)
cheers
Chris Maunder
|
|
|
|
|
So you can't just test for the existence of the newly named old column by its new name and handle accordingly (and where necessary)? In code and queries. Seems a safe and simple-minded solution. Handles itself, and some day you just strip out the conditional (while doing some other upgrade?).
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
W∴ Balboos wrote: So you can't just test for the existence of the newly named old column by its new name and handle accordingl
Where do you put it?
Keep in mind that additions are the easiest. There are deletions and updates. For the latter think about a column that has been split into two new columns.
And consider agile where you might have 100 changes in month and several rollouts and now 3 months later complications start to arise due to overlaps.
|
|
|
|
|
1 - No difference. If the new column exists then all the operations operate on the new set of fields; if it doesn't exist, use the old set.
2 - I don't consider agile. You example - which strongly implies a rush to just have something to show - anything - underscores my distaste. I'm of the school of thought: try to do it right the first time.
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
W∴ Balboos wrote: No difference. If the new column exists then all the operations operate on the new set of fields; if it doesn't exist, use the old set.
Which means, after a while, that you are going to have a lot of conditional code.
W∴ Balboos wrote: I'm of the school of thought: try to do it right the first time.
I have been doing databases for 30 years. Never worked anywhere where the database was static.
Been doing startups for 20 years. And persistence models are definitely dynamic in those.
|
|
|
|
|
jschell wrote: Which means, after a while, that you are going to have a lot of conditional code.
Actually, no. The idea is to have the conditional during the transition and then remove it.
Even if you only get around to removing it when you put in the next conditional during the next round of changes.
Note (back to the thread start) that they wanted to shut things off after some future point in time. The conditional methodology is a work-around and doesn't need any date setting. It just keeps working, and, as updates are done the just work.
However . . .
Accumulating conditionals, if that is what colored your comments, is something with which I agree. It all becomes an ugly patchwork and is bound to collapse.
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
W∴ Balboos wrote: The idea is to have the conditional during the transition and then remove it.
Even if you only get around to removing it when you put in the next conditional during the next round of changes.
Which is why I prefer it to be separate.
With it embedded in the code you end up with the following problems.
1. How to detect it
2. How to handle things like indexes, constraints
3. What happens if two places need the same update
4. Prioritizing the code removal
5. How to determine that it can be removed.
|
|
|
|
|
I don't think you have a choice but to go down for maintenance man. Adding temp code just seems like a bad idea for production environments. It'll also clutter up the code base in source control.
Is there any way you can do the rollout in chunks at least instead of all servers at once?
Jeremy Falcon
|
|
|
|
|
This is reasonably common over in the django world. You just do a double deployment.
The first deployment migrates the data into a new column and transmogrifies it as needed. The second deployment brings the newer code and does the other half of the migration.
Of course, the real solution is not to have whatever's going on be as coupled. Your application layer shouldn't care so much about your data layer.
|
|
|
|
|
Asday wrote: the real solution is not to have whatever's going on be as coupled. Your application layer shouldn't care so much about your data layer.
|
|
|
|
|
No, I haven't heard of anything like that.
Typically, when I have to do something like this, I just write a small, SIMPLE app that does the work and insert it into the DB migration portion of the deploy script.
|
|
|
|
|
Most code seems to self destruct as soon as users get their hands on it anyway, so ...
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Isn't that just a simple case of the app checking for updates?
I've got that pretty much standard in larger apps,
compares date of itself (and dependencies) against the same file name(s) in a read-only deployment directory,
if newer version fire off the [external to avoid file lock] updatater and exits (also passing command args to updater)
updater does it's work and fires off the app again with the same args.
simple, efficient, unattended.
Installing Signature...
Do not switch off your computer.
|
|
|
|
|
An app rewriting itself is really the closest I could envision at the moment. An update is close, but it's a wholesale replacement, not a chameleon like morphing.
cheers
Chris Maunder
|
|
|
|
|
This is getting onto the realms of TI-99s when code could overwrite itself. It was almost always a very bad idea.
We're philosophical about power outages here. A.C. come, A.C. go.
|
|
|
|
|
API versions?
veni bibi saltavi
|
|
|
|
|
It might be a change to your current processes but one way is to use batch scripts to handle this sort of thing.
This is how we make these changes where I work.
All DDL and DML changes are scripted in files and these scripts are then run against the database on a weekly or twice weekly basis in the case of sprint releases.
There will inevitably be a few minutes downtime while the DDL scripts run.
This then keeps your maintenance scripts outside of the application and also enables you to keep track of changes made to the database outside of the application.
...or have I completely misunderstood you.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
Our issue is merely a catalyst for what I was thinking about. There's tons of ways to change our process, but it's more about the concept of code actively changing itself: you write a small hack, and a week later that hack has gone. The code actively cleans up itself. Maybe the IDE is involved. Maybe it's the compiler.
Just thinking.
cheers
Chris Maunder
|
|
|
|
|
The first thing that comes to mind for me is conditional compilation, tied to the targeted version of the DB you are compiling for (the variable you must set/control, like compiler versions).
Then combined with an IDE feature (Plugin) that goes X revs back to suggest/clean as you go.
I cannot imagine it being done in one step. Using a DB versioning system, we would target a specific X.Y version.
#ifdef DBVER_MM = 7.4
...
#endif
A quick scan of DBVER_MM (Major.Minor) would find removable code. But a plugin could handle it for you to manage the version # of the DB, and suggest/clean the old revs of the code.
The challenge is that you MUST know 2 things:
1) The target DB version: Which changes over time
2) which code will be "targeted" (both for compile time inclusion, and for effective cleaning)
And you should know how long, you want to keep that code around in case it needs to be re-used or reviewed. The good news is that it should also be in revision control.
Just some thoughts.
|
|
|
|
|
when u mean code you mean like c# or tsql... ?
well if you have a ORM framework you just update the code and it updates the database and later you
shut the update mechanism and your unit tests take care of the checking...
Caveat Emptor.
"Progress doesn't come from early risers – progress is made by lazy men looking for easier ways to do things." Lazarus Long
|
|
|
|
|
I've got (desktop lob) apps that have been in deployment for over 10 years. One of the first things an application does after connecting to the database is to check it's version against the database version. A special table is used to record schema changes, currently adding a simple tinyint (either exists or not, and if so completed successfully or not) descriptively named column for single or batch mod...if I had it to do over, I might rather use a row-based solution to record more details per database mod. (such as comments/notes, datetime applied, app version, or even an optional expiration date)
Running an older app against a newer database simply nags for an application update and warns of the possible consequences of non-compliance. (only happens occasionally in multi-user scenarios) 
Edit: Nevermind...after reading more it seems like you're after AI! 
"Go forth into the source" - Neal Morse
modified 16-Oct-17 14:41pm.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
