Guildenstern
Guildenstern

Reputation: 3801

Is there another way to deal with niche flags in tables?

Say you have a table meal that you have been using in your application for many years. You have always been using this table to serve meals. But now you need to be able to make meal drafts before they are (optionally) made. So you add a new boolean column draft to the meal table; these meals are not to be served since the user has not confirmed that they want to make this particular meal. So they need to only be available in the draft dialog and nowhere else.

The drafts need to be persisted since a user might close the dialog and want to get back to the preview later.

Actual meal serving is still the backbone of your application. So now you need to update all of the queries to check that this flag is false. This is a lot of work and you have to be very careful, since forgetting one query might turn into a pretty subtle bug.

You could perhaps duplicate the meal table creation and make a new table called draft_meal, but this is the central table in your application (related to many other tables) and you have to update meal to add things like new columns etc. pretty regularly.

Is there another way to deal with this? Is there a way to deal with niche flags that “pollute” the whole application?

Upvotes: 1

Views: 40

Answers (1)

O. Jones
O. Jones

Reputation: 108696

You can change the name of your existing table to something like meal_master as you add the new column. Then create a view something like this:

CREATE OR REPLACE VIEW meal AS
SELECT col, col, ... 
  FROM meal_master
 WHERE draft = 0

That approach allows you to keep your existing code going as you add your new feature. You can go live with less risk to your existing service.

You should still refactor everything to use the new table; you just don't have to do it in a big bang.

Make sure draft's default value is 0.

You're learning that data lives longer than the code that uses it.

Upvotes: 2

Related Questions