docs: move EAN8 product directories

[stephanegigandet]

• To fix Store EAN-8 products in /products/000/001/234/5678 openfoodfacts-server#3818

[alexgarel]

there is a script for that openfoodfacts/openfoodfacts-server#7249

[alexgarel]

Will you also update old versions .sto ?

[stephanegigandet]

I'm not planning to.

[alexgarel]

This means you have to change the code of those projects too ?

[stephanegigandet]

Yes. Or we move them first to the new code.

[alexgarel]

What is your plan for the migration ? (better write it down to follow it the D day).

As I understand we first deploy the new product opener version.

Then we run the script.

I would personally prefer a safe path of running the script with ProductOpener down (ideally it could be up in read only mode, but I don't think we have this feature ;-) ).

[alexgarel]

Also if we do it with ProductOpener down, don't forget to also stop the various services that might attend to it (generate_feeds_*, minion, cloud_vision).

[stephanegigandet]

I'm thinking I can make it transparent: if the old path exists, Product Opener uses it, otherwise it uses the new path. That way products can be moved at any time. And once the migration is 100% complete, I remove the check for the old path.

[alexgarel]

Another strategy that I can think of:

• deploy a code that use new code normalization for computing path for new products, but is able to fallback on the old one (if the normalized path does not exists, try the non normalized one)
• run the script when you want
• deploy a code with support only for normalized code

[stephanegigandet]

In effect, that's what we do. We check if the old path exists and use it if it does, we use it. It has the same effect as checking first if the new path exists. (unless if for some reason both paths exist..)

[teolemon]

Does this mean we have to update our path building logic for the Dart packages (and others) if we have any @stephanegigandet @monsieurtanuki

[monsieurtanuki]

Does this mean we have to update our path building logic for the Dart packages (and others) if we have any @stephanegigandet @monsieurtanuki

@teolemon In dart we do compute the barcode subfolder for all the product images:

  /// Returns the barcode sub-folder (without trailing '/').
  ///
  /// For instance:
  /// * `12345678` for barcode `12345678`
  /// * `123/456/789` for barcode `123456789`
  /// * `123/456/789/0` for barcode `1234567890`
  /// * `123/456/789/0123` for barcode `1234567890123`
  static String getBarcodeSubPath(final String barcode) {

The first step would be to give ourselves more flexibility, like static String getBarcodeSubPath(String barcode, bool newEAN8mode).

Then everywhere in Smoothie when we display an image, use the "old" EAN8 syntax and the "new" 00000 syntax as a fallback. We don't store image file paths, we compute them on demand.

I've double-checked, that could have been problematic in Smoothie when we write (e.g. crop) an image as our methods currently compute and return the file path. But eventually we don't use those paths: as we work on background tasks, all we care about is if the task failed or not, and the changed data will be provided by the refreshed data of the product.

That will impact only the EAN8, of course.

In Smoothie we can start now to support the old then the new syntax as fallback.

[stephanegigandet]

@monsieurtanuki @teolemon

the server still support the old paths, but yes we should update the logic in the Dart package.

/// * 12345678 for barcode 12345678
/// * 123/456/789 for barcode 123456789

That will impact only the EAN8, of course.

Also others, e.g. 9 digit 123456789 is now in 000/012/345/6789. We not only split the EAN8, when we compute paths, we pad all codes with 0s so that they have 13 digits.

[alexgarel]

Kudos for this though work !