|
I'm -10 brave...
I don't know what it is but... I won't try it...
|
|
|
|
|
Let me just take a look at the code,If what u re telling me is true then after putting the code through I will see a better result.I want to change my life.There is this local bank that doesn't seems to reveal anything when it comes to foreign openings to transactions.Tell me exactly what I need to do.
|
|
|
|
|
|
Do not chat with complete strangers. Problem solved. 
|
|
|
|
|
|
Rajesh R Subramanian wrote: Do not chat with complete strangers.
That would be the end of CodeProject. 
There are two kinds of people in the world: those who can extrapolate from incomplete data.
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
From today’s daily news:
Microsoft pleads for more enterprise Windows 10 Insider recruits[^]
Well, I did opt in with 1 of my home PC’s, the one with no important programs / data. Last Friday I was the lucky one to receive the fall update, nice, from 20:00 till 01:00 the computer was totally unusable.
At my work (24x7x365) we still using Windows 7, have to upgrade someday. This “nice” update experience really made me doubt about Windows 10 (as a service, if I deliver such service I can look for another job) in our production environment.
Twice a year a reimage of all physical PC’s, we don’t have the resources.
Citrix in a box, we have some experience but doesn’t exist anymore.
Terminal server (remote apps), have some nice and more important, less nice experience.
Maybe just go back to Windows XP on a segmented network with a nice firewall, even Linux comes to mind. Porting our software to Linux will cost a huge amount of resources, which we don’t have.
Don’t know which way Microsoft Windows 10 is going but it looks like “from us”, not “towards us”
Opt in the insider program with a work PC, no way. It’s there to get work done, not to wait for a 5 hour update before you boot and wait another hour before you can actually use it for any work.
|
|
|
|
|
The problem for me is that I used to be an MS beta tester in the DOS days (when they called it "beta testing" rather than "RTM") and the overwhelming feeling you got was "screw you". Find a problem - who cares? Here's some software that not only doesn't fix it it breaks other stuff.
I gave up, because it was all hassle without reward. And there doesn't appear to have been any change ...
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
With all the money MSFT makes in selling this stuff and with their new data slurping window 10 .. why should users suffer..
Caveat Emptor.
"Progress doesn't come from early risers – progress is made by lazy men looking for easier ways to do things." Lazarus Long
|
|
|
|
|
Peter Sentveld wrote: Opt in the insider program with a work PC, no way. It’s there to get work done, not to wait for a 5 hour update before you boot and wait another hour before you can actually use it for any work.
And testing your new platform to see how your product works in the future is not part of your "work"? Is a test-PC deemed "too expensive"?
Peter Sentveld wrote: At my work (24x7x365) we still using Windows 7
Sounds very secure, I hope I'm not a customer 
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
We do test, on 4 PCs. Last week patched them (one after the other) and started the automated tests. Next day an email with the differences, if any.
With this update its goanna take a week before we know the result on 4 PC’s
We make small well defined changes, making sure we stay in control. The Windows.Old directory after the “Fall update” is nearly 30 GB. It really makes me nervous. Who is in control?
I’m pretty sure you have something with parts originating our company. Consider those made in a controlled environment, with well tested in-house made software making sure nothing is wrong with the quality.
|
|
|
|
|
Peter Sentveld wrote: It really makes me nervous. Who is in control?
Dunno; but the changes were pleasant enough to make me try Ubuntu.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
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 the standard pattern to add a nullable column, then once the data's all there, make it non-nullable?
|
|
|
|
|
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?).
| 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: 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.
| 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: 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.
| 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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
