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 in
the database.  It seemed that the correct thing to do would be to
introduce an enumeration for the personal title and store the enumeration
id 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 email
templates would be updated to make use of this new column via a
new/updated view-entity that would include the personal title enumeration
description.

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 a
new one)

The best practice is described here:

http://docs.ofbiz.org/display/OFBTECH/General+Entity+Overview

see 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 the
UI/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.


Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to