This is something that I found in one of my recent projects.
There are a list of exception messages which is being fetched from DB.
After fetching from the Database the first time, the messages are stored in a cache and then used from cache from there on.
There are nearly 30 exception messages which need to be utilised as we progress in the application.
When asked the lead, he says "we didn’t want to keep maintaining that in a properties file which will ideally end up in udeploy"
Now, while I understand that this is a bad practice to maintain the business exception messages in Database, what is the better way that we can do without ending up in maintaining in Udeploy?
If there is any good link which will say that putting exception messages in DB is bad, please let me know.
Putting error messages in a database versus putting them in a configuration file for the application? I wouldn't have an opinion until I knew more about the environment the application is running in. And by that I don't just mean the hardware and software, I also mean the people in charge of running and maintaining the application. Things like whether there are other configuration items, why the error messages are different than those other items, who is in charge of those messages and other configurations, etc.
posted 9 months ago
Thanks for responding!
Here below is the whole story.
It is a maven project involving technologies like Springboot and ORM framework.
The DB is oracle and we have a constants file from which constants are consumed, properties file which gets loaded to udeploy and the Java files with usual J2EE project structure.
The properties file is used to load the properties needed for starting the application.
We developers act as maintenance people also to maintain the application
With this scenario, I see that having 30-35 exception messages in database as a bad way to design a web application.
Because I feel business exception messages are supposed to be taken from the business layer and not from the DB layer.
Though the reason given is that we are forced to deploy every time we see a change or maintenance of the exception message(s)
My suggestion is to have these messages added as part of the constants file itself, and frequest deployment cannot be a reason for a poor design!
If you had to redeploy twice a day then I as management might well be concerned about that. But these are exception messages we're talking about. My feeling is that exception messages would rarely be changed, and that changes would coincide with programming changes which would require a redeploy.
If you want to press your point with management then I'd recommend quantifying what I just wrote. How often are the exception messages changed? Do those changes usually coincide with other changes which would require a redeploy? That's the data you would need. (This is assuming your management is responsive to using information like that as a basis for decision-making.)
posted 9 months ago
Awesome! Thanks a lot Paul.
Your answer makes it all clear.