Database Maintainability

Database Maintainability

1. Can the logs be more meaningful?
2. Can the system add a function that would remove unused tables?

Just a background on why i am raising these issues:
I am currently migrating data from our old system to outsystems.
I got several errors that were hard to understand even when looking at the logs.
The errors were regarding foreign keys. 
In my action, I already deleted all the data that were dependent on the table in question.
So i didn't have any idea why the deletion of the data in the table was raising any foreign key contraint errors.
I visited the database and got a list of the tables representing each entity that was related to the entity that I was trying to empty out. I visited each table to look for the specific contraint that was occuring.
I found out that the problem was that during development several instances of a table were created for a specific entity. There were data that were inputted to these tables. Since these data were still pointing to the entity, i could not delete the records in it.

I was able to find the error but it took a long time to look for it. Having to visit the database itself to look for the specific constraint is time consuming and exsasperating. 

Have you checked the Ideas page? I would definitly vote for more meaningful logs.
You really DON'T want more meaningful error message with the current system. "What? That's nuts!" is what you are thinking (and I don't blame you).

The reason why, is because virtually everyone implements a pattern on every Screen Action where there is an "All Exceptions" handler which feeds to "Feedback Message". This means that all of the errors that you see in the logs also get sent to the user's screen. Any more description in the logs will provide a "malicious user" (aka: someone trying to crack your security) with information that they will find very useful in breaking your system. As it is, it is bad enough that we are giving away table names!

Even if you don't have a security concern, it is still going to put extremely technical error messages up on the screen.

The third challenge is that those error messages are coming from your database, not OutSystems. It is the DB's responsibility to check constraints and such, not the platform's responsibility. That said, OutSystems could do a better job at looking at the error message or code for the most common issues (record not found, a few various constraint issues, data too large for destination field, etc.) and adding additional information or inspect the query, inspect the constraints and such, and provide better information.

I too want to see more descriptive errors in the logs... and in the Session.Exception object when debugging... but with the current model of the Exception object, this would be a bad idea.

I think that the right solution is to have the Exception object get split up a bit. It should have a "User Friendly Message" and a "Technical Message" in them, with the "Technical Message" being much more descriptive and the "User Friendly Message" being much friendlier to end users.

I would assume that the message that would be displaying on the ExceptionFeedbackMessage should be replaced once you get out of the development stage of the application. Perhaps in production, It should be replaced with a user friendly message and an email containing the real exception would be sent to the admin.

In development it would be helpfull for the developer to know as much as possible. 

Thanks for the suggestion.
Marion -

Yes, that makes sense.

What I do is I *never* let my screens directly access the DB or anything else like that. I have an eSpace devoted to the data access, and all of my actions there return a very standardized object that have the ID, a success/failure boolean, and a Record List of messages (using a structure with the RichWidgets MessageType and a Text field). Each action in that layer has a generic "All Exceptions" handler which wraps the messages up nicely, and a TON of validation to catch errors and provide a gentle message (and log the ugly message) up to the caller.

Then, at the screen level, all they need to do is call the action, do a Feedback Message using the MessageType and Text returned, and an if on the IsSuccess to determine the next steps.

The end result is that we see far fewer true "exceptions" and our users virtually never see one of those ugly messages, and I can use my exception handlers to capture much richer information if I need to (like user ID, parameters being passed in, etc.).

I know it's not automated or built-in like you are asking for, but it really does help the overall problem.