September 16, 2018 at 9:07 pm
Comments posted to this topic are about the item Dark Reads During a Migration
September 17, 2018 at 3:10 am
It's definitely a good plan and I like the thinking.
"That's if you are given time to fix any issues you find.."
Essentially that is the rub - getting time. I think experience and heft of reputation can give you the necessary weight to push back on schedules and get the time to do all those things. Still, you don't always have the energy / presence of mind to do that. I guess the answer is - make sure you do develop that energy and get the job done properly.
September 17, 2018 at 3:49 am
Given the variability of the preferences this could be an example of where a good Document DB would fit.
Of course if youvyo got the in-house skills to keep an existing DB platform up and running the pain of learning the essentials that people forget exist might outweigh the benefits
September 17, 2018 at 11:11 am
Rod at work - Monday, September 17, 2018 10:35 AMWhat is dark launching? I searched for it, but all results are blocked by my employer, so I need someone to tell me here, what dark launching is, please.
You release prospective new version/new features of some software to just a subset of users who are then like the beta testers for the release.
Sue
September 17, 2018 at 11:34 am
Sue_H - Monday, September 17, 2018 11:11 AMRod at work - Monday, September 17, 2018 10:35 AMWhat is dark launching? I searched for it, but all results are blocked by my employer, so I need someone to tell me here, what dark launching is, please.You release prospective new version/new features of some software to just a subset of users who are then like the beta testers for the release.
Sue
Thank you, Sue. Sounds like A-B testing to me. Anyway, thank you.
Kindest Regards, Rod Connect with me on LinkedIn.
September 17, 2018 at 12:48 pm
It could be a/b, but that's usually releasing one version (a) to most everyone and another version (b) to a selected group.
Dark launching would be feature flags or feature toggles that aren't visible to anyone without turning them on. These could be set to turn on for groups, or they could be on/off for everyone, depending on the toggle.
In the database world, this might be adding a column to a table that the application doesn't use or worry about. It gets launched/deployed to production, maybe populated with data, maybe with a trigger, maybe random data to load test, but at some point the application changes versions and starts using the column, which is now in the light.
Here's a good piece to read: https://martinfowler.com/articles/feature-toggles.html
September 17, 2018 at 1:08 pm
Not to be confused with a "BlackOps" deployment, which is when (hypothetically speaking) a feature currently in prototype or beta is deployed to production temporarily, perhaps under a special schema called [unittest] or [dba], so it can be field tested for performance. I can neither confirm nor deny involvement in such a deployment.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
September 18, 2018 at 8:27 am
Steve Jones - SSC Editor - Monday, September 17, 2018 12:48 PMIt could be a/b, but that's usually releasing one version (a) to most everyone and another version (b) to a selected group.Dark launching would be feature flags or feature toggles that aren't visible to anyone without turning them on. These could be set to turn on for groups, or they could be on/off for everyone, depending on the toggle.
In the database world, this might be adding a column to a table that the application doesn't use or worry about. It gets launched/deployed to production, maybe populated with data, maybe with a trigger, maybe random data to load test, but at some point the application changes versions and starts using the column, which is now in the light.
Here's a good piece to read: https://martinfowler.com/articles/feature-toggles.html
Thank you Steve, for the additional clarification.
Kindest Regards, Rod Connect with me on LinkedIn.
September 18, 2018 at 5:31 pm
You are welcome. This sis the way I'd like to see all database deployments and then better app code with inserts qualifying columns lists, defaults on columns, no select *, etc. If you do this, then it becomes easy to update your database.
This also usually means you need to schedule cleanup to remove old columns, which is something people struggle to do.
September 19, 2018 at 9:35 am
Views are also a good way to abstract the application from the underlying data model: hiding columns the application doesn't need, computed columns, row filtering, or switching in a new version of the underlying tables.
In the distant past, I was faced with a scenario where multiple end user teams were interfacing with a database I was developing. The problem is that each team had their own ideological opinions on naming conventions. Also, some developers were doing the SELECT * thing and would get miffed when I added a new column to support another team. So, to make each team feel like they were my One-True-Love :rolleyes:, I implemented three sets of views on top of the tables, each with a different naming convention and subset of columns meaningful to that a teams's use case.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply