Array of Floats metadata

Metadata
1

Morning LEAF,
Is there a standard approach to defining metadata for an ordered (LinkedHashSet?) array of Floats? I am looking for something like SetOfStringsFieldMetadata except maybe,

SetOfFLoatsFieldMetadata

But that doesn’t exist in the LKB. I am guessing that I should make the metadata use strings for my float values, then cast them back to floats when I use the values in code.

Happy Wednesday folks, and thanks for your help.

sg

2

Hey there! I have dreams of LEAF some day implementing generic Set/List fields, but unfortunately those do not exist yet. We implemented SetOfStringsFieldMetadata mainly because needing a(n ordered) set of string values is a super common use case.

The three approaches for making a Set of Floats field that come to mind are:

  • Misuse SetOfStringsFieldMetadata and parse the strings as floats when reading and stringify when writing. Or similarly just use StringFieldMetadata and turn the set into a csv, like {"type": "Person", "favoriteNumbers": "10.234,5.981,-3.0"}.
  • Make a custom FieldMetadata called SetOfFloatsFieldMetadata. For Mongo and Transient, you can pretty easily get full support you’d expect down to the data store keeping the values as floating point numbers. For SQL, we have the limitation you have to store the field by decomposing to one or more pre-existing FieldMetadata type(s) (ie StringFieldMetadata or SetOfStringsFieldMetadata). But even with SQL, while working in-memory, you can make the value appear as Set<Float>.
  • Or put in a feature request ticket, and possibly the LEAF team could take a stab at it. I think it’s more likely we look into generic collection fields (ie Set of some pre-supported type, not just SetOfFloats specifically).

The second option would probably be the fastest, and pretty nice for Mongo/Transient usage. I wouldn’t mind you putting in a ticket though, at least so we can track the use case.

1 Like
3

Note that SetOfStringsField is an “ordered set” and will drop duplicate values, so is not a safe replacement if your use case is an “array”.

1 Like
4

@mark.a.alvaro I have created a custom FieldMetadata type for Mongo. It coded-up easily enough, with one problem.

In my SetOfFloatsFieldMetadata.java file I define the class as such:

public class SetOfFloatsFieldMetadata extends BaseFieldMetadata
{…}

I don’t calculate anything, so I don’t implement ICalculatedFieldMetadata as the LKB does.

The problem is with the @Overide implement getFieldIdentifer()

    @Override
    public IFieldIdentifier<SetOfFloats> getFieldIdentifier() {
        return null;
    }

The LKB example has this:

    // **********************************
    // *  Other Implementation(s)
    // **********************************

    @Override
    public TirePressureFieldIdentifier getFieldIdentifier() {
        return new TirePressureFieldIdentifier(getPropName());
    }

So in my code I have:

    @Override
    public SetOfFloatsFieldIdentifier getFieldIdentifier() {
        return new SetOfFloatsFieldIdentifier(getPropName());
    }

Which doesn’t satisfy the extended BaseFieldMetadata requirement that I implement, which requires getFieldIdentifier to return an IFieldIdentifier.

If a huddle and screen share is better just let me know.

sg

5

Yep definitely free for a huddle. Feel free to hit me up on Slack.

Also wanted to mention, if your value class is SetOfFloats (you made a custom value class called SetOfFloats.class), then I’d use the TirePressureFieldIdentifier example. But if your value class is Set<Float>, I’d look at the Generics section of the Create an IFieldIdentifier page. It specifically shows how to make a SetOfTirePressuresFieldIdentifier whose value class is Set<TirePressure>.