This code will self-destruct in...
-
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
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.
-
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.
-
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
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.
-
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
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. ;)
Latest Article - Class-less Coding - Minimalist C# and Why F# and Function Programming Has Some Advantages Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
-
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.
:thumbsup::thumbsup:
-
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
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.
:rolleyes:
:rolleyes:
:rolleyes:
:rolleyes:
:rolleyes:
:rolleyes:
:rolleyes:
:rolleyes:
:rolleyes:
:rolleyes:
:rolleyes:
:rolleyes:
:rolleyes:
:rolleyes:
:rolleyes:
:rolleyes:
:rolleyes:
:rolleyes:
:rolleyes:
:rolleyes:
:rolleyes:
:rolleyes:
:rolleyes:
:rolleyes:
:rolleyes:
:rolleyes:
:rolleyes:
:rolleyes:
:rolleyes:
:rolleyes:
:rolleyes:
:rolleyes:
:rolleyes:
:rolleyes:
:rolleyes:
:rolleyes:
:rolleyes:
:rolleyes:
:rolleyes:
:rolleyes:
:roll
-
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
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
-
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
We do exactly the same thing. That example was merely an example. I'm looking more towards code that actively changes itself.
cheers Chris Maunder
-
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
We have views and stored procedures between the data and the applications. If I need to migrate a column to a different name or size, I 1. add the new column, 2. add code to the create and update procedures to update the new column as well as the old, 3. manually copy the old data to the new data, 4. change the views to use the new column (if adding new functionality rather than migrating, use ISNULL() as needed), 5. make new versions of the procedures (I add a number to the name for that purpose) to use the new column, 6. change the application in development and testing to use the new procedures, 7. deploy the new version of the application. Later, after the data and application have been backed up or updated several times, I can delete the old versions of the procedures.
-
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
Add a "date >= ??? or" or "negation and" statement to your if statement so that it automatically gets or doesn't get called after a certain date. Another option for enabling is if you can send a cleaner code to remove the if/then statement by converting it to whitespace and leaving the braces as is. Then the code will get called thereafter. GoTo statement? :)
-
Add a "date >= ??? or" or "negation and" statement to your if statement so that it automatically gets or doesn't get called after a certain date. Another option for enabling is if you can send a cleaner code to remove the if/then statement by converting it to whitespace and leaving the braces as is. Then the code will get called thereafter. GoTo statement? :)
I'm thinking I'll just ditch if/then/while and for statements altogether and use goto.
cheers Chris Maunder
-
I'm thinking I'll just ditch if/then/while and for statements altogether and use goto.
cheers Chris Maunder
-
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.
-
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.
-
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
-
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?).
"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.
-
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
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?
Haven't heard of it. I wouldn't use it. I version the database. Each instance has a version number table which includes at least the version number and a timestamp. The application knows what version(s) it will deal with and will refuse to run (exit) if the version is not allowed. Separate process updates the database, when completed it updates the version table. Each version consists of one or more updates that are blocked together. That means that every so often one can just delete the oldest blocks (say 6 months ago) so that they no longer run. Presumption is that there are no older databases at that point (if selling a product then the updated product would include the old install and thus the update.) Naturally it is under version control so it is always retrievable.
-
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.
"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
-
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.
:rolleyes:
:rolleyes:
:rolleyes:
:rolleyes:
:rolleyes:
:rolleyes:
:rolleyes:
:rolleyes:
:rolleyes:
:rolleyes:
:rolleyes:
:rolleyes:
:rolleyes:
:rolleyes:
:rolleyes:
:rolleyes:
:rolleyes:
:rolleyes:
:rolleyes:
:rolleyes:
:rolleyes:
:rolleyes:
:rolleyes:
:rolleyes:
:rolleyes:
:rolleyes:
:rolleyes:
:rolleyes:
:rolleyes:
:rolleyes:
:rolleyes:
:rolleyes:
:rolleyes:
:rolleyes:
:rolleyes:
:rolleyes:
:rolleyes:
:rolleyes:
:rolleyes:
:rolleyes:
:roll
Bug fixed. Sorry that took so long.
cheers Chris Maunder
-
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. :laugh:
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