You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Bob Morley <rm...@emforium.com> on 2009/06/04 17:43:22 UTC
Adding an enumeration for Person -> PersonalTitle
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-tp23872556p23872556.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: Adding an enumeration for Person -> PersonalTitle
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
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.
>
Re: Adding an enumeration for Person -> PersonalTitle
Posted by David E Jones <de...@me.com>.
How would this be better than the current practices? These are
described here:
http://docs.ofbiz.org/display/OFBTECH/Revisions+Requiring+Data+Migration
and here:
http://docs.ofbiz.org/display/OFBTECH/General+Entity+Overview ->
Deprecated Entities
-David
On Jun 27, 2009, at 10:58 PM, Harmeet Bedi wrote:
> How about this proposal
> 1. Add enumeration id in addition to text field for these and any
> other
> places where text could be replaced with reference. Some locations
> (a) add Person::salutationTypeId references
> PersonSalutionType:salutationTypeId
> (b) add Person:personalTitleTypeId references
> PersonPersonalTitleType:personalTitleTypeId
> (c) add Person:nameSuffixTypeId references
> PersonNameSuffixType:nameSuffixTypeId
> (d) add PostalAddress:cityGeoId references Geo:geoId
>
> 2. Leave text fields alone for backward compatibility. But add
> support for
> deprecated attribute.
> (a) Mark existing fields the correcsoond as deprecated by adding a
> deprecated="true" attribute.
> (b) Change enitymodel.xsd
> <xs:attributeGroup name="attlist.field">
> ....
> <!-- proposed deprecated attribute -->
> <xs:attribute name="deprecated" default="false">
> <xs:simpleType>
> <xs:restriction base="xs:token">
> <xs:enumeration value="true"/>
> <xs:enumeration value="false"/>
> </xs:restriction>
> </xs:simpleType>
> </xs:attribute>
> ....
> (c) If 'check-on-start' == true in entityengine.xml, and a field
> is
> deprecated, log a warning.
>
> 3. Create migration scripts for (1) with CreateOrRetrieveReference
> logic.
> Migration would make existing text fields available as references to
> enum so
> that id based strong checking is possible. Now this does not
> migrate, but if
> someone wants to move their app to drop down or lookups.. it makes it
> easier.
>
> thoughts ?
> Harmeet
>
> On Sat, Jun 27, 2009 at 11:57 PM, Harmeet Bedi
> <ha...@gmail.com>wrote:
>
>> Regd: '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'
>>
>> Migration could check and create the enumerated option if it does not
>> exist.
>> So Party has refrences to PersonalTitleId, where PersonalTitleId =
>> CreateOrRetrieveReference(text field PersonalTitle)
>>
>> There maybe a similar pattern with city in PostalCode. It(city) is
>> text but
>> there is a need to constrain city value to limited set(e.g. to
>> avoid typos).
>>
>> There may be other cases in schema where text can be modelled as an
>> enumerated type.
>>
>> I understand the motivation of not breaking other apps that rely on
>> text,
>> but wondering if there should(or is) 'deprecated' style annotation
>> to nudge
>> movement to stronger reference checks at schema level. Having
>> enumeration
>> type reference does not prevent a UI functionality to show text
>> field(if
>> that is what the app requires) but the service at the backend has
>> much more
>> increased complexity to do createOrRetrieve rerference
>>
>> thoughts ?
>> Harmeet
>>
>>
>>
>>
>> On Sat, Jun 27, 2009 at 2:46 PM, David E Jones <de...@me.com> wrote:
>>
>>>
>>> Yeah, that's the exact issue with the title too... there are
>>> potentially
>>> thousands of them if you try to include every culture in the world
>>> (and
>>> hundreds even for English speaking cultures, especially if you
>>> include
>>> royalty/class titles, military titles, etc). On the other hand,
>>> now that I
>>> think about it more, maybe that's why they want a drop-down: to
>>> restrict it
>>> a certain small set of available titles. Anyway, supporting both
>>> still seems
>>> the way to go.
>>>
>>> -David
>>>
>>>
>>>
>>> On Jun 27, 2009, at 12:17 PM, Tim Ruppert wrote:
>>>
>>> I would say yes - but it does limit us to what we know about - but
>>> that's
>>>> the case with any lookup.
>>>>
>>>> Cheers,
>>>> Tim
>>>> --
>>>> Tim Ruppert
>>>> HotWax Media
>>>> http://www.hotwaxmedia.com
>>>>
>>>> o:801.649.6594
>>>> f:801.649.6595
>>>>
>>>> On Jun 27, 2009, at 11:32 AM, David E Jones wrote:
>>>>
>>>>
>>>>> On Jun 27, 2009, at 8:07 AM, Jacopo Cappellato wrote:
>>>>>
>>>>> On a side note, would you want to do this with the suffix or any
>>>>> other
>>>>>>> fields?
>>>>>>>
>>>>>>>
>>>>>> I am sorry but I don't understand the above question.
>>>>>>
>>>>>
>>>>> The questions was mainly for Bob, but I guess something for
>>>>> anyone to
>>>>> consider: would we want to have drop-downs for things like the
>>>>> Person.suffix
>>>>> field (ie Esq., II, III, Jr., Sr., Ph.D., MD, etc, etc) and
>>>>> perhaps others
>>>>> fields?
>>>>>
>>>>> -David
>>>>>
>>>>>
>>>>
>>>
>>
Re: Adding an enumeration for Person -> PersonalTitle
Posted by Harmeet Bedi <ha...@gmail.com>.
How about this proposal
1. Add enumeration id in addition to text field for these and any other
places where text could be replaced with reference. Some locations
(a) add Person::salutationTypeId references
PersonSalutionType:salutationTypeId
(b) add Person:personalTitleTypeId references
PersonPersonalTitleType:personalTitleTypeId
(c) add Person:nameSuffixTypeId references
PersonNameSuffixType:nameSuffixTypeId
(d) add PostalAddress:cityGeoId references Geo:geoId
2. Leave text fields alone for backward compatibility. But add support for
deprecated attribute.
(a) Mark existing fields the correcsoond as deprecated by adding a
deprecated="true" attribute.
(b) Change enitymodel.xsd
<xs:attributeGroup name="attlist.field">
....
<!-- proposed deprecated attribute -->
<xs:attribute name="deprecated" default="false">
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:enumeration value="true"/>
<xs:enumeration value="false"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
....
(c) If 'check-on-start' == true in entityengine.xml, and a field is
deprecated, log a warning.
3. Create migration scripts for (1) with CreateOrRetrieveReference logic.
Migration would make existing text fields available as references to enum so
that id based strong checking is possible. Now this does not migrate, but if
someone wants to move their app to drop down or lookups.. it makes it
easier.
thoughts ?
Harmeet
On Sat, Jun 27, 2009 at 11:57 PM, Harmeet Bedi <ha...@gmail.com>wrote:
> Regd: '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'
>
> Migration could check and create the enumerated option if it does not
> exist.
> So Party has refrences to PersonalTitleId, where PersonalTitleId =
> CreateOrRetrieveReference(text field PersonalTitle)
>
> There maybe a similar pattern with city in PostalCode. It(city) is text but
> there is a need to constrain city value to limited set(e.g. to avoid typos).
>
> There may be other cases in schema where text can be modelled as an
> enumerated type.
>
> I understand the motivation of not breaking other apps that rely on text,
> but wondering if there should(or is) 'deprecated' style annotation to nudge
> movement to stronger reference checks at schema level. Having enumeration
> type reference does not prevent a UI functionality to show text field(if
> that is what the app requires) but the service at the backend has much more
> increased complexity to do createOrRetrieve rerference
>
> thoughts ?
> Harmeet
>
>
>
>
> On Sat, Jun 27, 2009 at 2:46 PM, David E Jones <de...@me.com> wrote:
>
>>
>> Yeah, that's the exact issue with the title too... there are potentially
>> thousands of them if you try to include every culture in the world (and
>> hundreds even for English speaking cultures, especially if you include
>> royalty/class titles, military titles, etc). On the other hand, now that I
>> think about it more, maybe that's why they want a drop-down: to restrict it
>> a certain small set of available titles. Anyway, supporting both still seems
>> the way to go.
>>
>> -David
>>
>>
>>
>> On Jun 27, 2009, at 12:17 PM, Tim Ruppert wrote:
>>
>> I would say yes - but it does limit us to what we know about - but that's
>>> the case with any lookup.
>>>
>>> Cheers,
>>> Tim
>>> --
>>> Tim Ruppert
>>> HotWax Media
>>> http://www.hotwaxmedia.com
>>>
>>> o:801.649.6594
>>> f:801.649.6595
>>>
>>> On Jun 27, 2009, at 11:32 AM, David E Jones wrote:
>>>
>>>
>>>> On Jun 27, 2009, at 8:07 AM, Jacopo Cappellato wrote:
>>>>
>>>> On a side note, would you want to do this with the suffix or any other
>>>>>> fields?
>>>>>>
>>>>>>
>>>>> I am sorry but I don't understand the above question.
>>>>>
>>>>
>>>> The questions was mainly for Bob, but I guess something for anyone to
>>>> consider: would we want to have drop-downs for things like the Person.suffix
>>>> field (ie Esq., II, III, Jr., Sr., Ph.D., MD, etc, etc) and perhaps others
>>>> fields?
>>>>
>>>> -David
>>>>
>>>>
>>>
>>
>
Re: Adding an enumeration for Person -> PersonalTitle
Posted by David E Jones <de...@me.com>.
On Jun 27, 2009, at 9:57 PM, Harmeet Bedi wrote:
> Regd: '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'
>
> Migration could check and create the enumerated option if it does
> not exist.
>
> So Party has refrences to PersonalTitleId, where PersonalTitleId =
> CreteOrRetrieveReference(text field PersonalTitle)
Yes, that's true. I guess this discussion is now getting into
implementation details as opposed to general approach and certainly
things like this will come up.
You would probably still want to do data cleansing before running
this, and perhaps map multiple values in the live data to a single
enumerated option. For example you might have "Doctor", "Dr", "Dr.",
"Doc", etc all mapped to the enumerated ID of "DOCTOR". But yeah, that
is just a standard part of doing data migration.
> There maybe a similar pattern with city in PostalCode. It(city) is
> text but
> there is a need to constrain city value to limited set(e.g. to avoid
> typos).
This is a good example where using an external system might be a
better approach than implementing and maintaining all of the possible
enumerated values, and their corresponding constraints (ie city to
postal code relationships).
> There may be other cases in schema where text can be modelled as an
> enumerated type.
>
> I understand the motivation of not breaking other apps that rely on
> text,
> but wondering if there should(or is) 'deprecated' style annotation
> to nudge
> movement to stronger reference checks at schema level. Having
> enumeration
> type reference does not prevent a UI functionality to show text
> field(if
> that is what the app requires) but the service at the backend has
> much more
> increased complexity to do createOrRetrieve rerference
Ummm... isn't it easier to go from an enumerated ID to displayable
text than to go from free-form text entry to an enumerated value?
As for how important this is: consider that you may have a requirement
right now that you are working with, but flexibility should be a
priority even for you because the requirement may change for your
current project, or you may have a different requirement for you next
project. Aside from that, chances are others have different
requirements and it's good to explore those and collaborate with
others to determine adequate solutions that are also sufficiently
flexible. Otherwise the project becomes more difficult to customize
over time and is no longer as generally useful.
-David
> On Sat, Jun 27, 2009 at 2:46 PM, David E Jones <de...@me.com> wrote:
>
>>
>> Yeah, that's the exact issue with the title too... there are
>> potentially
>> thousands of them if you try to include every culture in the world
>> (and
>> hundreds even for English speaking cultures, especially if you
>> include
>> royalty/class titles, military titles, etc). On the other hand, now
>> that I
>> think about it more, maybe that's why they want a drop-down: to
>> restrict it
>> a certain small set of available titles. Anyway, supporting both
>> still seems
>> the way to go.
>>
>> -David
>>
>>
>>
>> On Jun 27, 2009, at 12:17 PM, Tim Ruppert wrote:
>>
>> I would say yes - but it does limit us to what we know about - but
>> that's
>>> the case with any lookup.
>>>
>>> Cheers,
>>> Tim
>>> --
>>> Tim Ruppert
>>> HotWax Media
>>> http://www.hotwaxmedia.com
>>>
>>> o:801.649.6594
>>> f:801.649.6595
>>>
>>> On Jun 27, 2009, at 11:32 AM, David E Jones wrote:
>>>
>>>
>>>> On Jun 27, 2009, at 8:07 AM, Jacopo Cappellato wrote:
>>>>
>>>> On a side note, would you want to do this with the suffix or any
>>>> other
>>>>>> fields?
>>>>>>
>>>>>>
>>>>> I am sorry but I don't understand the above question.
>>>>>
>>>>
>>>> The questions was mainly for Bob, but I guess something for
>>>> anyone to
>>>> consider: would we want to have drop-downs for things like the
>>>> Person.suffix
>>>> field (ie Esq., II, III, Jr., Sr., Ph.D., MD, etc, etc) and
>>>> perhaps others
>>>> fields?
>>>>
>>>> -David
>>>>
>>>>
>>>
>>
Re: Adding an enumeration for Person -> PersonalTitle
Posted by Harmeet Bedi <ha...@gmail.com>.
Regd: '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'
Migration could check and create the enumerated option if it does not exist.
So Party has refrences to PersonalTitleId, where PersonalTitleId =
CreteOrRetrieveReference(text field PersonalTitle)
There maybe a similar pattern with city in PostalCode. It(city) is text but
there is a need to constrain city value to limited set(e.g. to avoid typos).
There may be other cases in schema where text can be modelled as an
enumerated type.
I understand the motivation of not breaking other apps that rely on text,
but wondering if there should(or is) 'deprecated' style annotation to nudge
movement to stronger reference checks at schema level. Having enumeration
type reference does not prevent a UI functionality to show text field(if
that is what the app requires) but the service at the backend has much more
increased complexity to do createOrRetrieve rerference
thoughts ?
Harmeet
On Sat, Jun 27, 2009 at 2:46 PM, David E Jones <de...@me.com> wrote:
>
> Yeah, that's the exact issue with the title too... there are potentially
> thousands of them if you try to include every culture in the world (and
> hundreds even for English speaking cultures, especially if you include
> royalty/class titles, military titles, etc). On the other hand, now that I
> think about it more, maybe that's why they want a drop-down: to restrict it
> a certain small set of available titles. Anyway, supporting both still seems
> the way to go.
>
> -David
>
>
>
> On Jun 27, 2009, at 12:17 PM, Tim Ruppert wrote:
>
> I would say yes - but it does limit us to what we know about - but that's
>> the case with any lookup.
>>
>> Cheers,
>> Tim
>> --
>> Tim Ruppert
>> HotWax Media
>> http://www.hotwaxmedia.com
>>
>> o:801.649.6594
>> f:801.649.6595
>>
>> On Jun 27, 2009, at 11:32 AM, David E Jones wrote:
>>
>>
>>> On Jun 27, 2009, at 8:07 AM, Jacopo Cappellato wrote:
>>>
>>> On a side note, would you want to do this with the suffix or any other
>>>>> fields?
>>>>>
>>>>>
>>>> I am sorry but I don't understand the above question.
>>>>
>>>
>>> The questions was mainly for Bob, but I guess something for anyone to
>>> consider: would we want to have drop-downs for things like the Person.suffix
>>> field (ie Esq., II, III, Jr., Sr., Ph.D., MD, etc, etc) and perhaps others
>>> fields?
>>>
>>> -David
>>>
>>>
>>
>
Re: Adding an enumeration for Person -> PersonalTitle
Posted by David E Jones <de...@me.com>.
Yeah, that's the exact issue with the title too... there are
potentially thousands of them if you try to include every culture in
the world (and hundreds even for English speaking cultures, especially
if you include royalty/class titles, military titles, etc). On the
other hand, now that I think about it more, maybe that's why they want
a drop-down: to restrict it a certain small set of available titles.
Anyway, supporting both still seems the way to go.
-David
On Jun 27, 2009, at 12:17 PM, Tim Ruppert wrote:
> I would say yes - but it does limit us to what we know about - but
> that's the case with any lookup.
>
> Cheers,
> Tim
> --
> Tim Ruppert
> HotWax Media
> http://www.hotwaxmedia.com
>
> o:801.649.6594
> f:801.649.6595
>
> On Jun 27, 2009, at 11:32 AM, David E Jones wrote:
>
>>
>> On Jun 27, 2009, at 8:07 AM, Jacopo Cappellato wrote:
>>
>>>> On a side note, would you want to do this with the suffix or any
>>>> other fields?
>>>>
>>>
>>> I am sorry but I don't understand the above question.
>>
>> The questions was mainly for Bob, but I guess something for anyone
>> to consider: would we want to have drop-downs for things like the
>> Person.suffix field (ie Esq., II, III, Jr., Sr., Ph.D., MD, etc,
>> etc) and perhaps others fields?
>>
>> -David
>>
>
Re: Adding an enumeration for Person -> PersonalTitle
Posted by Tim Ruppert <ti...@hotwaxmedia.com>.
I would say yes - but it does limit us to what we know about - but
that's the case with any lookup.
Cheers,
Tim
--
Tim Ruppert
HotWax Media
http://www.hotwaxmedia.com
o:801.649.6594
f:801.649.6595
On Jun 27, 2009, at 11:32 AM, David E Jones wrote:
>
> On Jun 27, 2009, at 8:07 AM, Jacopo Cappellato wrote:
>
>>> On a side note, would you want to do this with the suffix or any
>>> other fields?
>>>
>>
>> I am sorry but I don't understand the above question.
>
> The questions was mainly for Bob, but I guess something for anyone
> to consider: would we want to have drop-downs for things like the
> Person.suffix field (ie Esq., II, III, Jr., Sr., Ph.D., MD, etc,
> etc) and perhaps others fields?
>
> -David
>
Re: Adding an enumeration for Person -> PersonalTitle
Posted by David E Jones <de...@me.com>.
On Jun 27, 2009, at 8:07 AM, Jacopo Cappellato wrote:
>> On a side note, would you want to do this with the suffix or any
>> other fields?
>>
>
> I am sorry but I don't understand the above question.
The questions was mainly for Bob, but I guess something for anyone to
consider: would we want to have drop-downs for things like the
Person.suffix field (ie Esq., II, III, Jr., Sr., Ph.D., MD, etc, etc)
and perhaps others fields?
-David
Re: Adding an enumeration for Person -> PersonalTitle
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
Hi David,
On Jun 27, 2009, at 1:42 AM, David E Jones wrote:
>
> 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.
>
Yours are all good points and so maintaining both of them seems like a
good solution.
> On a side note, would you want to do this with the suffix or any
> other fields?
>
I am sorry but I don't understand the above question.
Jacopo
> -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.
>>
>
Re: Adding an enumeration for Person -> PersonalTitle
Posted by David E Jones <de...@me.com>.
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.
>
Re: Adding an enumeration for Person -> PersonalTitle
Posted by Bob Morley <rm...@emforium.com>.
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.