|
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
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
