Adding an enumeration for Person -> PersonalTitle

[Bob Morley]

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

[Bob Morley]

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

[Jacopo Cappellato-4]

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.
>

[David E. Jones-2]

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.
>

[Jacopo Cappellato-4]

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.
>>
>

[David E. Jones-2]

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

[Tim Ruppert]

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
>

[David E. Jones-2]

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
>>
>

[Harmeet Bedi]

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 <[hidden email]> 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
>>>
>>>
>>
>

[Harmeet Bedi]

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 <[hidden email]>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 <[hidden email]> 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
>>>>
>>>>
>>>
>>
>

[David E. Jones-2]

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  
> <[hidden email]>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 <[hidden email]> 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
>>>>>
>>>>>
>>>>
>>>
>>

[David E. Jones-2]

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 <[hidden email]> 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
>>>>
>>>>
>>>
>>