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