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
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
-
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
How to Ask Is your question about programming? We prefer questions that can be answered, not just discussed. Provide details. Share your research. If your question is about this website, ask it on meta instead. visit the help center » asking help » :laugh:
-
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
Sounds like you want self morphing code, similar to [Self-Morphing C# Binary - bytecode77](https://bytecode77.com/hacking/poc/self-morphing-csharp-binary) As also recommended, I've seen devs load branches of code / assemblies based on version in a database/configuration file. So version 1 load mydatabasetier.v1.dll version 2 load mydatabasetier.v2.dll Seems like a lot of extra overhead.
Common sense is admitting there is cause and effect and that you can exert some control over what you understand.
-
Sounds like you want self morphing code, similar to [Self-Morphing C# Binary - bytecode77](https://bytecode77.com/hacking/poc/self-morphing-csharp-binary) As also recommended, I've seen devs load branches of code / assemblies based on version in a database/configuration file. So version 1 load mydatabasetier.v1.dll version 2 load mydatabasetier.v2.dll Seems like a lot of extra overhead.
Common sense is admitting there is cause and effect and that you can exert some control over what you understand.
Very cool, but it's changing the compiled code, not the actual source code. But very cool even so :)
cheers Chris Maunder
-
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
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.
-
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.
"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
-
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.
"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.