0

So I'm working on a project that I was introduced to a year ago. One of the features of project involves alarming the users when certain events are triggered. There is also a log of these events. First you need to understand this:

  1. Not all alarms generate event logs
  2. Events can be logged without generating alarms.

The design of this involves flat files that hold a bunch of information about the events and the alarms. This includes everything from where the alarms are sent, priority levels, etc.

What happens in the code is when an event is trigger, it sends a message with a bunch of data attached to it to a process that reads in the flat files, replaces the data appropriately, and then routes it.

My question is this:

Is it normal design to save all this information outside of the code. We're running into problems when we deploy because we have to ensure that the flat files and the code are in sync. It's created some troubleshooting nightmares, and it honestly just feels like more hassle then just having a class dedicated to this stuff, and shipping it with the code.

  • 3
    Flat files tend to survive power failures better than in-memory data structures. – Dan Pichelman May 28 '15 at 18:35
  • 1
    "We're running into problems when we deploy because we have to ensure that the flat files and the code are in sync." - so why don't you put the version of the flat files which corresponds to the version of the code into the deployment? Or are your flat files something the user of your software is allowed to customize, so you cannot replace them easily at each deployment? – Doc Brown May 28 '15 at 20:40
  • 1
    This problem has had people struggling since the early days of computing. You just need to pick your poison. Flexibility versus robust but rigid. Doc Brown gave the best solution. Keep version strings. If you load an old version then replace it with the new version of the file. That only works if new fields have some reasonable default values that you can set. The other option is not to keep versions but set default values if the file is not in expected format and save the new version file. Once again, there's some types of data where this works, other types of data where it breaks the system. – Dunk May 28 '15 at 21:53
1

So, as I understand your question you save the configuration of the alarms/events in a file.

Its pretty normal to have configuration files. but I suspect from the tone of the question that you have taken it a step further in this case and have 'generic' system which you can use to make 'any' alarm/event and that the configuration has both configuration and elements of logic to it.

I think its a constant temptation to write systems this way. Obviously you want a flexible system that 'users' can configure without rewriting code.

However, in my view it can be a bad practice. As a system evolves and features are added, you have the choice to add them to config or to hard code them. The more features you add as configurable options, the more like a programming language your configuration becomes! You can end up with a very sketchy programming language/config, with lots of undocumented tricks and unversioned files.

Its not so much that its wrong to write a new programming language, but that you still have to apply the normal rigour of documentation, version control, deployments, testing etc which you would normally do with a new version of the code.

Also I would add that if you do create a generic alarm/event system, which is not specific to your business. Then you could probably have bought it off the shelf for a lot less than it took to write it.

  • I'm on the same page as you. It's nice because it allows the customer some level of configuration where code changes don't need to be made, but this product is now maintained in-house and specific to only our business(and not legal for sale). The only reason I don't think we'll throw it all within the code is because it will probably take quite a bit of work to undo all the original work, but that seems to be common theme. – Triplell89 Oct 6 '15 at 14:35
1

Is it normal design to save all this information outside of the code.

I think it is perfectly normal. You can use Observable pattern for handling events dispatching and store its configuration (actual subscriptions) inside, say, database.

I do not respect storing information in plain files. It is difficult to atomically change them and they are not intended for storing data of real complexity. Use at least SQLite database.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.