Allow the fields to be renamed for refactoring
When a spelling error is made in the name of a field, it is almost impossible to fix it for the moment.
Also, the older portions of OpenERP have not been coded with strict conventions and would benefit from refactoring.
We could probably extend the ORM to make these changes possible with automatic migration.
Blueprint information
- Status:
- Not started
- Approver:
- None
- Priority:
- Undefined
- Drafter:
- None
- Direction:
- Needs approval
- Assignee:
- None
- Definition:
- Pending Approval
- Series goal:
- Proposed for trunk
- Implementation:
- Not started
- Milestone target:
- None
- Started by
- Completed by
Whiteboard
Please discuss this blueprint on the Framework expert mailing list, and report conclusions here.
=== Refactoring use case ===
We could add a new parameter "replace" in osv.fields, so that an columns could be renamed in an object.
For example if version n includes :
class my_object(osv.osv):
_name = 'my.object'
_columns = {
'name': fields.char('Name', required=True, size=64, select=True),
'parent': fields.
'childs': fields.
}
Then in version n+1 we could refactor it (and still get it wrong, oops!) :
- 'childs': fields.
+ 'childdren': fields.
And in version n+2 we finally get it right :
- 'childdren': fields.
+ 'children': fields.
=== Runtime behavior expected on the server side ===
At runtime the server should throw a warning each time an old name is used, and still return the right data.
For example if we browse my_object then all replaced fields should be usable:
print my_object.childs # warning on the server console
print my_object.childdren # warning on the server console
print my_object.children # no warning
=== Behavior expected when upgrading a module ===
When the server encounters a "replace" option, for each field the server should test whether it still exists in the database table, and if it does, rename it to the new field name.
This would provide easy data migration for the use case above.