This is a tough one since you would be moving from a less constrained
field to a more constrained one, ie a free-form field to a field with
an enumerated set of options. Doing an automated migration would only
work if you know that all current values in the database are among the
enumerated options you want to migrate to (ie it may require some data
cleansing first, especially if you are migrating from a system that
allowed free-form text entry).
This is also tough because if we created a personalTitleEnumId field
and deprecated the personalTitle it would not be a backward compatible
change, and existing deployments that use a free-form text entry field
for this would have to add back the old field or add a custom one.
On the other hand, if we simply leave the personalTitle field as-is
and add an EnumerationType and various Enumeration records for title
options you could choose in your UI if you want it to be free-form or
as a drop-down populated from the database. This would be backward
compatible and be more flexible for future use. Actually, I think in
some places it already is a drop-down, just not populated from the
database.
On a side note, would you want to do this with the suffix or any other
fields?
-David
On Jun 26, 2009, at 5:04 PM, Bob Morley wrote:
Yes I am going to quote myself! LOL
I was hoping to get some input on this specifically in the area of the
migration concerns. In our application we have converted the
personal title
drop-down to an enumeration, but I still store the localized
personal title
value. We will definitely want to store the enumeration identifier
in the
entity and I need to decide if we should do that as custom work or
as part
of an Ofbiz patch.
So, a potential migration script would simply -- add a new
personalTitleEnumId, would attempt to convert the localized values
into this
new column, drop the personalTitle column.
Thoughts?
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?
2) What would we do with the old column (assuming we should
introduce a
new one)
3) How do we handle the data migration
4) Is it worth supporting backwards compatibility to the old column
in the
UI/Email templates; or would we force data migration
--
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.
