Sometimes its very difficult to represent some information into relational manner even if its easy to represent into objects. That time you might want to serialize your object into DB. One of the example of what I am taking about is storing expressions into DB. Its very difficult to find tabular representation of expressions e.g. How to represent x*y + (z-10) * (k ^ 3) into DB? But its very easy to represent them into object. In fact this expression is very primarily expression though.
I was working on RulesManagement module and as a part of implementation of the module I have defined certain classes representing various language elements like operators, conditional elements, variable representation etc. As we know rule requires condition to be defined as a part of it, and condition can be represented by expression. I was zeroed down to serialze object into DB. My decision worked well, I got lots of freedom on defining expressions. I was happy and everyday all my testcases were going green as a part of build process. One day suddenly I got all RED. I was clueless as I have not made any changes in my code since last 3 months. I and my team mates started doing root cause analysis. We spend around 2 hours and the result of this process was bit frustrating. My RuleSet class was extending Persistable class. Persistable class was part of our persistance framework and so we were extending all our object from this class if we want them to be persisted into DB. So I have extended RuleSet class from that one. That day somebody has made changes into Peristable class and so I was getting serial version UID error during deserialization of already persisted rulesets. Its very serious problem as business can never accept persisted rule not being retrieved back.
Lesson learnt:
Object to be serialized into DB should not extend from any class . It should simply implemetat Serializable interface. Also class to be serialized into DB must have default serial verison UID. If you go with generated serial version UID and over the period of time somebody modifies that because of some change in that class, you are screwed.
I was working on RulesManagement module and as a part of implementation of the module I have defined certain classes representing various language elements like operators, conditional elements, variable representation etc. As we know rule requires condition to be defined as a part of it, and condition can be represented by expression. I was zeroed down to serialze object into DB. My decision worked well, I got lots of freedom on defining expressions. I was happy and everyday all my testcases were going green as a part of build process. One day suddenly I got all RED. I was clueless as I have not made any changes in my code since last 3 months. I and my team mates started doing root cause analysis. We spend around 2 hours and the result of this process was bit frustrating. My RuleSet class was extending Persistable class. Persistable class was part of our persistance framework and so we were extending all our object from this class if we want them to be persisted into DB. So I have extended RuleSet class from that one. That day somebody has made changes into Peristable class and so I was getting serial version UID error during deserialization of already persisted rulesets. Its very serious problem as business can never accept persisted rule not being retrieved back.
Lesson learnt:
Object to be serialized into DB should not extend from any class . It should simply implemetat Serializable interface. Also class to be serialized into DB must have default serial verison UID. If you go with generated serial version UID and over the period of time somebody modifies that because of some change in that class, you are screwed.
