Hey everyone. I would like to contribute to trunk some more Uom (Uom,
UomType, UomConversion) seed data, and some more demo records that use Uom
data. I have found 2 issues that I will need input on before I can make a real
proposal.
ISSUE #1:
There is a uomTypeId="TIME_FREQ_MEASURE". However, the frequency units
have not been added to that. I will add the frequencies, but i suspect they
have not been added yet because there is no way to convert between time and
frequency.
It looks like UomConversion seems to assume that all conversions are of
type:
measured_value_uomIdTo = (conversionFactor * measured_value_uomIdFrom)
Are there plans to someday extend UomConversion, perhaps to be something
more allong the lines of:
measured_value_uomIdTo = conversionZeroOffset + (conversionFactor *
(measured_value_uomIdFrom ^ conversionExponent))
(This example would accommodate both frequency and the "how do i express 1
F = 1.8C + 32 ?" issue in the comments of UnitData.xml).
1 F = 32 + 1.8 * (C ^ 1)
1 Hz (frequency) = 0 + 1 * (second ^ -1)
So my issue #1 is: Are there plans for extending the UomConversion entity
to be able to handle more in the future? If not, then I propose the
frequencies should be moved to their own UomType, like:
<UomType description="Frequency (Cycles per second)" hasTable="N"
parentTypeId="" uomTypeId="FREQUENCY_MEASURE"/>
Issue #2:
Now there is a service "convertUom" in
component://common/groovyScripts/CommonServices.groovy that handles conversions.
From glancing at it, I don't think it does either recursive or join
searches for UomConversion yet (note, join searches are not appropriate for
UomConversionDated as things like currencies can get out of wack during
arbitrage opportunities so that converting from A to B, then B to C, then C to
A can yeild a profit.
If the convertUom service does not do either yet, then I propose it would
be best to enter conversion factors for "single join" searches in preparation
for the day convertUom gets extended.
<!-- =============== FREQUENCY_MEASURE =============== -->
<!-- Note that freqency is just 1/time . However, I dont see a way to
convert from Hz (I.E. one cycle per second) to secods in the UomConversion
system -->
<Uom uomId="FREQ_kHz" uomTypeId="FREQUENCY_MEASURE" abbreviation="kHz"
description="kiloHertz"/>
<Uom uomId="FREQ_MHz" uomTypeId="FREQUENCY_MEASURE" abbreviation="MHz"
description="MegaHertz"/>
<Uom uomId="FREQ_GHz" uomTypeId="FREQUENCY_MEASURE" abbreviation="GHz"
description="GigaHertz"/>
<Uom uomId="FREQ_THz" uomTypeId="FREQUENCY_MEASURE" abbreviation="THz"
description="TeraHertz"/>
<!-- Next is a SQL example of the "single join" way to do conversion
factors -- note that converting FREQ_THz to FREQ_kHz does not require recursion
-->
<UomConversion uomId="FREQ_THz" uomIdTo="FREQ_Hz"
conversion_factor="1000000000000"/>
<UomConversion uomId="FREQ_GHz" uomIdTo="FREQ_Hz"
conversion_factor="1000000000"/>
<UomConversion uomId="FREQ_MHz" uomIdTo="FREQ_Hz"
conversion_factor="1000000"/>
<UomConversion uomId="FREQ_kHz" uomIdTo="FREQ_Hz" conversion_factor="1000"/>
<!--A rough example (not tested) of a "single join" (non-recursive) search
for this would be like:
select all unit_from.conversion_factor / unit_to.conversion_factor
as conversion_factor
from uom_conversion as unit_from
join uom_conversion as unit_to using (uom_id_to)
where unit_from.uom_id = 'FREQ_THz' and unit_to.uom_id =
'FREQ_kHz' limit 1;
-->
<!-- Note this also allows a reasonable "pretyConvertUom" service to be
written that would just take 2 parameters of "uomIdIn" and "measuredValueIn"
and convert it to a valueOut and uomIdOut in "preferred units") -->
<!-- The other way of doing conversion factors (this would require a
recursive search to convert between THz and kHz) -->
<UomConversion uomId="FREQ_THz" uomIdTo="FREQ_GHz"
conversion_factor="1000"/>
<UomConversion uomId="FREQ_GHz" uomIdTo="FREQ_MHz"
conversion_factor="1000"/>
<UomConversion uomId="FREQ_MHz" uomIdTo="FREQ_kHz"
conversion_factor="1000"/>
<UomConversion uomId="FREQ_kHz" uomIdTo="FREQ_Hz" conversion_factor="1000"/>
(Note: The current seed data tends to use this form)
So my issue #2 is:
Has some decision been made that in the future we should go with "recursive
searches"?
(For example, does the "convertUom" in
component://common/groovyScripts/CommonServices.groovy already do, or is it
planned to be able to do recursive searches? If so then I should do it the
recursive way.
Otherwize I think I should do it the "join" way.
Thoughts?
CONFIDENTIALITY NOTICE: This message is intended only for the use of the person
or organization to which it is addressed or was intended to be addressed, and
may contain information that is privileged, confidential and exempt from
disclosure under applicable law. If the reader of this message is not the
intended recipient, or responsible for delivering the message to the intended
recipient, you are hereby notified that any dissemination, distribution or
copying of this communication is strictly prohibited. If you have received this
communication in error, please notify the sender immediately by email and
delete the original message immediately . The sender, its subsidiaries and
affiliates, do not accept liability for any errors, omissions, corruption or
virus in the contents of this message or any attachments that arise as a result
of e-mail transmission. Thank you.
