You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Development <D...@dlsemc.com> on 2020/09/30 20:08:18 UTC
Need input on extending the Uom Related seed data
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.
Re: Need input on extending the Uom Related seed data
Posted by Jacques Le Roux <ja...@les7arts.com>.
Hi NoName :),
Inline...
Le 30/09/2020 à 22:08, Development a écrit :
> 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"/>
+1, good idea
> 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"?
I can't remember any, not even discussions. From your comment about
"UomConversionDated as things like currencies"
I'd go with the simpler(?) way, ie no 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.
I'd have to check more but I don't think we do
> Otherwize I think I should do it the "join" way.
I tend to agree, though I did not thought much about it yet.
This is interesting: https://www.unitjuggler.com/convert-frequency-from-Hz-to-s(p).html?val=50
Jacques
>
> 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.