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:
+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.
(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.
