feat(Products): new 'quantity' field (synced with OFF)

[raphodn]

What

New Product.quantity field
Similarly to other fields on this model, we sync the data with OFF.

Why

The raw info could be used to

• parse it and use it instead of the existing product_quantity & product_quantity_unit fields
• manage edge cases where the above fields are empty (OFF quantity like "2 eggs" ; OPF quantity like "2")

[monsieurtanuki]

@raphodn I've just created openfoodfacts/openfoodfacts-dart#1158
I was thinking, could retrieving OFF data be optional? Or maybe we could provide a list of product fields? Less computation, lighter payload, avoiding undesired crashes when unwanted fields change formats?

[raphodn]

I was thinking, could retrieving OFF data be optional?

You mean clients choosing what they want to receive from the API ? I'm not even sure how to do this simply.
vs making small & rare changes and trying as much as possible not to break things.

adding a new field will also break the mobile ?

[monsieurtanuki]

You mean clients choosing what they want to receive from the API ?

Exactly

I'm not even sure how to do this simply.

Something like fields=code,quantity for the /api/v1/products/ queries I guess. How to code that in your own code is something else.
You probably store all the product data in your own database, so it probably wouldn't help dramatically with performances, as opposed to additional calls to OxF databases.
Smaller payload, though.

vs making small & rare changes and trying as much as possible not to break things.

Could work too.
Just keep in mind that even if I code very fast, the users will be in a grey zone for months before the app is published on google play then upgraded to each user's device.

adding a new field will also break the mobile ?

No, I don't care.

Anyway, I'm about to code something more resilient, where we don't un-json ALL fields by default, but only "just-in-time" for each field - which may mean never for some fields.