|
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.
|
|
|
|
|
That's a catchy idea. Although, he'd still run into the scenario of a newer app running against an older DB. And making an app work with N versions of the database (to address Chris' situation) is a loooooooot of overhead.
Jeremy Falcon
modified 16-Oct-17 14:27pm.
|
|
|
|
|
Chris Maunder wrote: 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?
Kindof. I always try to write very modular reusable components. For example I have a module that manages language resources in the database. I don't want to deal with that every time I start a new project. On the code side I have modules for the presentation tier, application logic, services, data access and entities. I only need to include these libraries and everything is ready - except the database. I do not have code to handle migrations, but when I run my project that now includes this module, it takes the database context and sets up the required tables if they are not there yet.
But speaking of migrations: How about Entity Framework code first?
I have lived with several Zen masters - all of them were cats.
|
|
|
|
|
Skynet  .
Jokes apart, I do not think there exists a framework/suit intelligent enough to "fix" itself like that. But AI is progressing fast, soon you may get what you want. Or maybe they'll take over our jobs.
Are you afraid?
I am not the one who knocks. I never knock.
In fact, I hate knocking.
|
|
|
|
|
I'm addressing only the "self-destructing" code part.
I use a plugin system with my code so that plugins can implement features undreamed of when the original code was deployed. You just drop the plugin dll into the appropriate folder. I can envisage a system that would simply unload the plugin when it's no longer needed and delete the dll. The original code (once it supports the plugin system) doesn't need to change at all.
Phil
The opinions expressed in this post are not necessarily those of the author, especially if you find them impolite, inaccurate or inflammatory.
|
|
|
|
|
Chris Maunder wrote: Has anyone ever heard of a system or language or framework that provides the means to have code self-destruct after a certain date?
It's called Windows Update. 
|
|
|
|
|
If the intent is just to make sure the temp code is removed from your code base after it's done its job you could just put something in the codebase to trigger a build error in debug after enough time's past that you think it should be done to remind you to remove it. I've found a kludge[^] that is supposed to work like a C++ static assert. Wrap it in an #if DEBUG and you should be good to go.
public void TempCodeExpiredAssert(DateTime expirationDate)
{
#if DEBUG
byte a = DateTime.Now > expirationDate ? 0 : -1;
#endif
}
PS, code is totally untested to avoid the no programming questions in the lounge rule.
PPS I reported the bug generating all the whitespace above my rolling eyes something like a year ago.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
Bug fixed. Sorry that took so long.
cheers
Chris Maunder
|
|
|
|
|
Chris Maunder wrote: Bug fixed. Sorry that took so long.
I figured that'd work, just had been waiting for the right opportunity for a few months.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
We setup a sort of versioning table that our migration scripts would run and add to at a previous work place. We had code to run the migrations in order, and only once. So we could easily run the deploy scripts against the database in any state along the way and be safe/confident.
Elephant elephant elephant, sunshine sunshine sunshine
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
