Re: Synchronizing constants/enums in database and code

As you have already figured out, there should only be one single representation of a fact in the system (The DRY principle from the Pragmatic Programmers).

So the question is where the fact is stated. Some ideas:

You can get it from the database as per your #4. But how does it get into the database in the first place? If you nuke the db, how do you rebuild it? I imagine that somewhere there are SQL scripts for default data.

If not, maybe there should be? Maybe those scripts could be used to determine the constants in the code?
If not, maybe the code could be responsible for setting up the default data in the database? It wouldn't have to do this all the time, but the information for doing it at scheduled upgrades could live in the code

Comment on Re: Synchronizing constants/enums in database and code

Replies are listed 'Best First'.
Re: Re: Synchronizing constants/enums in database and code by seattlejohn (Deacon) on Apr 13, 2004 at 16:21 UTC
Indeed, the DRY principle was the underlying motivator for my asking this question -- why do I have this in two places, and how am I going make sure they stay synchronized? I do have scripts that (re-)construct and (re-)populate the database. I'm really glad you brought that up, because considering them as part of the constellation of things that needs to stay in sync is leading me toward an approach I think I'm comfortable with. I'm now inclined to the constants in the code and generating the database table based on those same constants that the production code relies on. Of course I'll back that up with tests to make sure that I don't do something dumb like change the constants without reflecting those changes in the database. Thinking about it that way removes a lot of the unease I was feeling about this data being spread around instead of having one source of Ultimate Truth. Thanks for the replies, everyone! $perlmonks{seattlejohn} = 'John Clyman';	[reply]

Replies are listed 'Best First'.

Re: Re: Synchronizing constants/enums in database and code
by seattlejohn (Deacon) on Apr 13, 2004 at 16:21 UTC

I do have scripts that (re-)construct and (re-)populate the database. I'm really glad you brought that up, because considering them as part of the constellation of things that needs to stay in sync is leading me toward an approach I think I'm comfortable with.

I'm now inclined to the constants in the code and generating the database table based on those same constants that the production code relies on. Of course I'll back that up with tests to make sure that I don't do something dumb like change the constants without reflecting those changes in the database.

Thinking about it that way removes a lot of the unease I was feeling about this data being spread around instead of having one source of Ultimate Truth.

Thanks for the replies, everyone!

$perlmonks{seattlejohn} = 'John Clyman';

[reply]