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