In the near future I will have to face the problem of persisting Moose-based objects in a relational database which of course is not a problem as such.
Now presumably there will be an evolution as far as the objects/classes are concerned as new requirements need to be addressed or the code gets refactored - or put more simply: Some attributes could get added, other may get removed.
What I want to achive now is a way to decouple the evolution of the class-level from the database-level, i.e. I want to have a way to change (some) aspects of the class without having to change the database-schema (which from my experience gets messy once an application is in production).
So what I am thinking about is this:
All our classes will be based on Moose, i.e. they can be easily (and also generically) serialized as either XML or YAML.
So why not have one set of attributes that simply get mapped to database-fields of their own and at the same time have another set of attributes that get serialized as XML or YAML and that get then stored in a common CLOB field.
In this way I could change the latter set of attributes without affecting the database-schema.
The way I would implement it is via a class-trait that would allow individual attributes to be tagged as either belonging to the first or second group.
If the above is understandable at all: Does that make sense to you or would it be just a bad idea (if so why?).
This is just a vague idea I had (and by now I probably had one beer too many) so I am sorry if it just sounds like gibberish to you.
Many thanks anyway!
In reply to persisting Moose objects and schema evolution by morgon
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |