This code will self-destruct in...
-
Isn't the standard pattern to add a nullable column, then once the data's all there, make it non-nullable?
Nish Nishant Consultant Software Architect Ganymede Software Solutions LLC www.ganymedesoftwaresolutions.com
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
-
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
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!
-
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 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.
-
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?).
"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
-
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
API versions?
veni bibi saltavi
-
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
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
-
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
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
-
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
-
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
-
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'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! :laugh:
"Go forth into the source" - Neal Morse
-
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
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
-
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! :laugh:
"Go forth into the source" - Neal Morse
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
-
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? 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.
-
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
Skynet :-D . 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? :laugh:
I am not the one who knocks. I never knock. In fact, I hate knocking.
-
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
