Backend to Frontend state isn't properly handling complex data types #189
Comments
MJJoyce
added a commit
that referenced
this issue
Jan 21, 2021
Update handling of packet diffing to include complex types (Time, Cmd, and EVR) in with DN-to-EU values. This pushes human-readable info for these types to the frontend so clients don't need to inspect the dictionaries to determine what should be displayed. Update calls to `replace_datetimes` so the "dntoeu" diffs are passed instead of the raw ones. Previously these calls weren't doing anything since the passed diffs were always raw values. This was likely left in from a previous iteration on this functionality. Note, this doesn't make sweeping changes to the diffing code and instead works around the existing framework. The current stuff is a bit of a mess and could really use some TLC. We'll need to revisit this in a follow up ticket.
MJJoyce
added a commit
that referenced
this issue
Jan 21, 2021
Update the handling of Field format calls to fix issues encountered with formatting time data and to handle the new diffed data changes. Format calls are now always run over the raw data of a field instead the "human readable" data when dealing with complex types or when the value of the field is not a "number". This could result from enumerated values on non-complex field. Manipulations can then be performed as necessary on the data prior to the format call if the data type requires it. For example, in the case of a Time object we decode the raw value into a Date object prior to formatting it so the sprintf library handles it properly. The dtype definitions for Time32 and Time64 have been updated so they can be used to decode Date objects from raw values. Note, there's no clean up done here of the other code in dtype that is effectively dead given the changes to the front / backend transmission formats. That needs handled in a follow on ticket. Note, there is the possibility for semi-strange situations to occur with packet caching and the current format handling. For example, consider a command field that is not labelled as raw with values that are undefined opcodes. The "human readable" packet diff will mark this field as "Unidentified Cmd" any time the opcode doesn't decode properly. As such, this field could be incorrectly cached and ignored if the raw value changed but the "human readable" value didn't since the cache check occurs on the initial pulled value (which relies on raw = true / false). Effectively, this means that users may need to be more explicit with marking fields as raw=true. Similarly, formatting on a given raw / not value isn't always consistent since we need to support time value formatting. Unfortunately there isn't a great way to handle this without significantly reducing functionality and the caveats (e.g., you can't dump a time field to hex) aren't likely to cause too much pain and suffering.
MJJoyce
added a commit
that referenced
this issue
Jan 25, 2021
Issue #189 - Update diff handling of complex types and human readable values
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The current backend handling of raw / dn-to-eu values leaves a bit to be desired. Effectively, we're sending a delta of all the raw values and their respective DN-to-EU'd values if applicable. Given the desire to completely move away from the frontend calculating "stuff" where possible this results in a useful info missing from the front end. Namely, command, EVR, and enumerated telemetry field values. We need to consider treating the
dntoeuportion of the diff more as "DN to EU'd or human-readable values".The text was updated successfully, but these errors were encountered: