Hi Bob, I agree that adding the new personalTitleEnumId is a good idea. See also my comments inline:
On Jun 26, 2009, at 5:04 PM, Bob Morley wrote:
Bob Morley wrote:We had a requirement to add some additional values to the personal title dropdown and noticed that the list of Personal Titles were hardcoded in the application. Once more, they were stored with the localized value inthe database. It seemed that the correct thing to do would be tointroduce an enumeration for the personal title and store the enumerationid on the Person entity instead.Providing this is true, I have some questions about how to effectively handle the data migration this approach would take. My initial approach would be to add this new enumeration and create a new column on the Person entity (something like personalTitleEnumId). The UI artifacts and emailtemplates would be updated to make use of this new column via anew/updated view-entity that would include the personal title enumerationdescription. So here are my questions -- 1) Is there value in doing this / is this the right approach?
Yes.
2) What would we do with the old column (assuming we should introduce anew one)
The best practice is described here: http://docs.ofbiz.org/display/OFBTECH/General+Entity+Overviewsee section "Deprecated Entities", in particular the following paragraph:
"When changing the name of a field, or deprecating and replacing a field that does not require deprecation of the entire entity, then follow the same pattern leaving the old field there: a "old" prefix added to the field name, change the original first letter to upper case, and specify the column-name for the field so it is the same as the original field name. For example if you are changing the "uomId" field to a new name then change the field name to "oldUomId" and specify a column-name of "UOM_ID". Just as when replacing and entity, make sure to write a service to move the data from the old field to the new one. Whenever doing any of these sorts of changes that require additional steps to update a production server, ALWAYS add an entry on this page: Revisions Requiring Data Migration"
3) How do we handle the data migration
See above link, and have a look at the way the entity "OldOrderItemAssociation" (a deprecated entity) is used by the migration script in the "order" component.
4) Is it worth supporting backwards compatibility to the old column in theUI/Email templates; or would we force data migration
You should simply use the new field, the migration script should take care of the rest.
Cheers, Jacopo
-- View this message in context: http://www.nabble.com/Adding-an-enumeration-for-Person--%3E-PersonalTitle-tp23872556p24228477.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.
smime.p7s
Description: S/MIME cryptographic signature
