Ignoring computed fields in @Selection

[thinkpractice]

Hi there,

I'm migrating my weight tracking app to SharingGRDB/structured queries. So far, so good, but now I'm facing the following challenge. I would like to keep some computed fields in a selection:

Selection
struct WeightPoint
{
    let timestamp: Date
    let meanWeightInKilograms: Double
    @Ephemeral
    let weight: Measurement<UnitMass>

     init(timestamp: Date,
         meanWeightInKilograms: Double        
        )
    {
        self.timestamp = timestamp
        self.meanWeightInKilograms = meanWeightInKilograms
        self.weight = self.weightInLocalUnit(weightInKilograms: self.meanWeightInKilograms)
    }
}

However, the @Ephemeral doesn't seem to work. I would like to ignore self.weight as it throws a decoding error. It did work before with computed properties, but it seems the weight conversion is quite costly (?) and I would like to limit it to convert it only once, i.e. construct it in the constructor. Would there be a way to ignore the weight field in the selection? Or should I accomplish this better in an alternative way.

UPDATE: tried to do it with lazy vars but that doesn't compile, because the compiler says I'm trying to mutate an non-mutable object

kind regards,

Tim

[mbrandonw]

Hi @thinkpractice, is weightInLocalUnit really that expensive? That would be surprising to me if it's just a simple computation to convert units.

If you really want to do this you can always inline the code that the @Selection macro writes and modify the init(decoder:) to compute weight after the other fields have been decoded.

[thinkpractice]

Yeah was wondering the same. It comes back on top of the Instruments traces but may be smth else. So the Ephemeral macro only works on Table then?

thanks for the suggestion, will try to implement that tomorrow and see if it’s really the unit conversion or something else…

[mbrandonw]

@Ephemeral only works with tables, but even if we tried extending it to @Selection it wouldn't really help you here. It requires a default value, and you want to provide a value after the other fields have been initialized.

[thinkpractice]

@mbrandonw understood, thanks for the clarification! I guess the default value needs to be there because you need to initialize the fields in the macro? Or otherwise use optionals which would not be preferred in this context?

[mbrandonw]

Yeah, optional or default is necessary, and that doesn’t help you.

As I mentioned before, another alternative is to inline the macro and update the decoding logic to initialize your value after the other fields are decoded.