У них там какой-то CDN стоит, где пачка серваков с картинками и я так понимаю, они их чередуют. То есть картинки одни и те же, но, видимо, на каком-то из этих серваков они чуть иначе пожаты и я постоянно ловлю отчёты что картинки поменялись

вероятнее всего да, чуть разные настройки алгоритма сжатия и привет

Тут opencv поможет

Там вроде были такие алгоритмы сравнения

Ну а я бы сеточку обучил на это :)

сеточка как вариант да, но в любом случае там вычислительная сложность выше будет алгоритма в лоб, а точность не факт

https://github.com/mapbox/pixelmatch

https://github.com/mapbox/pixelmatch

Ага, и последние коммиты в некоторые файлы с сообщением "throw error on image size mismatch") Но если задача сводится к действительно "одинаковым" картинкам, то похоже на хорошее решение. ImageMagick тоже умеет такое, например.

Ну там оно под несколько специфичные цели, но посмотреть можно

Тем более если есть предположение что это из за пережатия

От пережатия спасёт, сам когда-то подобное внедрял, не помню даже на чём) Но вот любой ресайз/кроп/compose картинки - всё, труба. До гугла и всяких tineye - как до луны.

/stat@combot

/stat@combot

/stat@combot

господа, а кто как обновляет схему БД скажем монго дб, при обновлении приложения

скажем у вас релизится клиентам приложение, и нужно чтобы какие-нить поля добавились в коллекцию итд

как вы это делаете от релиза к релизу

?

Так схемы то нет

знал что будет такой вопрос

поэтому я "расширил" вопрос ниже предложением

В общем подход такой

Можно добавлять все поля как необязательные навсегда

Тогда ничего делать не нужно

я ща объясню к чему - я это. Вопрос консистенции. Когда я релижу сайтец у себя сам на сервере, в принципе это всеравно, но когда у тебя условно веб приложение, которое использует Компания А, ты ей отгрузил версию 1.0.0 но потом ты релизишься скажем несколько раз и там меняешь данные в бд, потом ребята хотят обновиться а БД поменялась скажем, получается что нужно добавлять как-то данные в коллекции

вот интересен опыт

кто как разруливает

я видел делают по принципу папочку и там скрипты, но видел я тока для SQL

как делается это для монги

Ну здесь можно сделать тоже самое

я тут нашел https://www.npmjs.com/package/database-updates

не знаю юзал кто?

Если речь о софте, который периодически обновляется, то это может непросто

Так как должна быть возможность мигрировать с произвольной версии

вот серия таких скриптов

на апдейт базы

и тогда можно с версии на версию

просто мало инфы вообще об этом

мало кто говорит вообще об этом

ну нужно чото типа привязки скриптов миграции БД к версиям релизов

вот тоже к этому склоняюсь

я бы делал по-нубски примитивно

На старте приложения проверяется формат БД и если он не тот, который нужен, то сразу на горячую и исправляется

Надёжно как топор

Слишком сложно проверять формат

Но кому-то не подойдёт из-за увеличенного на пару сотен миллисекунд времени запуска

Слишком сложно проверять формат

Ну в SQL не сложно

Тоже сложно

эээ чем?

Ну нужно проверить каждое поле на присутсвие по сути

Нет, надо проверить таблицы и типы столбцов

Да, именно

Ну и что тут сложного?

Это просто писать долго

Слишком много писать да

Поэтому вместо это сохраняют версию схемы

Но и то по первому разу

Версию схемы?

Да, в базе записана текущая версия схемы

Берется версия из базы и версия из кода

И выполняются все миграции между ними

Ок, ты проверил, она не та, которая нужна, твои действия?

ERROR: S client not available

Ну то есть у тебя всё равно написан миллион скриптов миграций

Да, но по крайней мере там код который реально нужно выполнять

не понял твою мысль

а бывает другой код?

Если проверять по одному полю, то будет много лишней работы

для меня или машины?

Например, когда ты в реальности добавил 10 полей за раз

для меня или машины?

И то и то

Для меня работы не меньше, чем скрипт миграции написать

а машинное время оно для того и создано чтобы работу выполнять

Тем более, поля могут зависетб друг от друга

И проверять их нужно в определенном порядке

типа foreign key?

Нет

а как?

Допусти мы хотим добавить поле A, в него прописать какое то значение по дефолту

так

Затем мы хотим добавить поле B, и прописать в него по дефолту то же, что и в A

так

Соответственно, поля нужно всегда проверять именно в таком порядке

И порядок этот поддерживать руками

Ну а в скриптах миграции как-то решена эта проблема?

В том что каждая миграция пишется отдельно и потому не трогается, и все они пишутся в конретном порядке

Ну ты проверки тоже пишешь в каком-то порядке

И тоже отдельно — по версиям приложения

Разве нет?

Просто создается много дополнительных состояний, которые нужно проверять

Например, проверяешь, что есть поле B, но нет поля A

Хотя в реальности если есть B, то A уже должно быть

Но в принципе можно сделать примерно похожее поведение