уважаемые знатоки

вопрос - это миграция или нет?

key-value ваще пофиг что ты в нее пихаешь

диску похуй что ты в него пишешь процессору похуй что ему считать. какой толк об этом говорить ?

диску похуй что ты в него пишешь процессору похуй что ему считать. какой толк об этом говорить ?

а ты мастер улавливать тенденции:D

а почему условие "только если а нечетное"?

а почему условие "только если а нечетное"?

а вот так захотелось, задача так стоит

ну ты сам сказал - не похуй бизнеслогике. зачем говорить о том кому похуй я не понимаю

можно это условие убрать, тогда две записи поменяются - вторая и третья

но не все

ну тоесть переносим схему на бизнеслогику. у нас теперь пропадает схема или что ?

посчитать и записать в базу можно как угодно. В базе сохраняется вариант объекта без поля с, значит миграции нет

ну тоесть переносим схему на бизнеслогику. у нас теперь пропадает схема или что ?

разумеется, на уровне базы - пропадает

вот ты и понял все

мы продолжаем поддерживать обе схемы

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

посчитать и записать в базу можно как угодно. В базе сохраняется вариант объекта без поля с, значит миграции нет

правильно рассуждаешь, на деле будет зависит от реализации базы

разумеется, на уровне базы - пропадает

это ты не понял. мы просто понятие базы поднимаем до уровня бизнес логики

мутабельная она или основана на теймстемпах

это ты не понял. мы просто понятие базы поднимаем до уровня бизнес логики

не базы, а схемы, формата, типа, вычислений, джобов - похер

это ты не понял. мы просто понятие базы поднимаем до уровня бизнес логики

тогда это не базой уже называется

ты в коде у себя можешь обмазаться чем угодно, но миграции в key-value от этого не появятся, если ты руками не приведешь архитектуру к этому виду

вот и вывод - миграции по дефолту в key-value не нужны, а какую бизнес-логику ты поверх накрутишь - это уже вопрос к тебе самому

тогда это не базой уже называется

только это и называется базой т.к. это инфраструктура которая охраняет данные непротиворечивыми и дает доступ к ними работать

если я в key-value храню жсон блобы, то от того, что я один раз пройдусь, поменяв все блобы в новый формат, хуже не станет

только это и называется базой т.к. это инфраструктура которая охраняет данные непротиворечивыми и дает доступ к ними работать

нет

данные у тебя лежат в key-value

данные у меня лежат на харде

а в коде у тебя бизнес-логика поверх этих данных

только это и называется базой т.к. это инфраструктура которая охраняет данные непротиворечивыми и дает доступ к ними работать

хорошо. но тогда это уже монга получается, а не key-value хранилище

поверх харда есть слои

данные у меня лежат на харде

ну да, но ты же не будешь по этому поводу задвигать, что ФС не нужны

которые эти данные дрочат

потому что они не умеют в схему данных

они то умеют

они то умеют

хаха. нет

они то умеют

вот тут точно пиздеж

просто схема там про иноды и файлики

вот мы тебя и поймали

т.е. про доступ до блобов

просто схема там про иноды и файлики

ну вот и в key-value схема тогда, по твоей логике - ключи и блобы

мета данные не есть схема

только это не схема, а метаданные

мета данные не есть схема

+

в общем, ты хочешь от key-value того, чего там не должно быть архитектурно вообще никак

ну извне в фс конечно не схема

можешь написать руками, а можешь не писать и жить спокойно

да, признаюсь я понял этот прием. я понял по какому праву монгорачье говорит про отсутствие схем и миграций

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

да, признаюсь я понял этот прием. я понял по какому праву монгорачье говорит про отсутствие схем и миграций

наоборот, на скейле только так и можно работать

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

нет я не про скейл

или можешь, но что-нибудь сломается по дороге

нет я не про скейл

ну так key-value ценен именно в контексте скейла

ну извне в фс конечно не схема

а теперь фс замени на key-value

ну в этом и проблема

там тоже самое получается key= inode а блоб - это value

и эту фигню ты не можешь никак изменить

ну в этом и проблема

в этом решение - мы уходим от реляционного ада и всяких “миграций” и просто пишем бизнес-логику

а схемы менять можнааа

вы почему то считаете что переместив всю логику в аппликацию вы с чистой совестью можете просто расчленить систему на "о бля вот у нас кейвалуе с блобами а что в блобах нас не ебёт"

в этом решение - мы уходим от реляционного ада и всяких “миграций” и просто пишем бизнес-логику

хорошо. понятие миграции для бизнеслогики ты тоже отрицаешь ?

ну потому что получается уже новая бд, которая не key-value

вы почему то считаете что переместив всю логику в аппликацию вы с чистой совестью можете просто расчленить систему на "о бля вот у нас кейвалуе с блобами а что в блобах нас не ебёт"

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

хорошо. понятие миграции для бизнеслогики ты тоже отрицаешь ?

я же выше писал - ты можешь реализовать бизнес-логику таким образом поверх key-value, что у тебя будут классические миграции. Но это - замшелая практика, которая на большом скейле не работает и в общем случае не нужна

а монго - говно на очень большую долю как раз потому, что этого не понимает

если классические то миграции. а если неоклассические то не миграции )

не умеет скейлиться и нарушает zero-one-infinity правииило

ERROR: S client not available

если классические то миграции. а если неоклассические то не миграции )

напиши мне свое определение “миграции базы данных”

вот хорошее определение

мы продолжаем поддерживать обе схемы

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

но надо определить что такое схема. этим я сейчас займусь

это определение имеет смысл только в контексте, если есть схема

а тут ее нет вообще

да, а схема есть всегда

нет

ну давай я определю

я тебе выше написал - вот у тебя key-value, у каждого документа своя, независимая структура

ну давай я напишу сначала

там нет никакой схемы, есть просто куча json-документов

ну давай я напишу сначала

пиши

ну по идее схема - это описание структуры единицы данных

ну по идее схема - это описание структуры единицы данных

погоди, пусть напишет

ок

он слился чтоль?

думает, видимо

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

например, представим себе стартап - “умный гитхаб”. Хранится не сам код, а AST по каждому файлу с кодом, то есть дерево синтаксиса, чтобы код было легко анализировать. И лежит это все в каком-нибудь хранилище типа Elasticsearch. Так вот - есть документы, есть у них ключи-айдишники и есть таймстемп их добавления в базу

схемы нет и не может быть в принципе, потому что каждый документ - результат парсинга AST. Ты можешь сделать запрос, чтобы узнать, например, в каких документах используется оператор goto или какие документы не соответствуют pep8

и миграций тут тоже, соответственно, быть никаких не может в принципе

не ну точно слился

может быть даже осознал свою ошибку и сделал себе сэппуку

схема это тип тип это информация о том то что мы пишем и то что мы хотим получить читая ну очевидно говорить про "схему вообще" не имеет никакого смысла потому что работа с данными идёт снизу вверх и идет постоянно. т.е. если мы работаем на уровне фс то мы имеем дело с инодами, конкретными форматами и нам не похуй какая у них схема. если мы поднимаемся на уровень выше то нам похуй на структуру данных в которой хранится таблица файликов мы просто имеем интерфейс уровня открыть файл, прочитать/записать байты, и файлу похуй что в этих байтах хранится, для него это байты теперь идём дальше - есть кейвалуе с жсоном. самому кейвалуе похуй что находится в жсоне, он просто знает что это жсон. может ла ним быть похуй какая схема у системы в целом ? может, но по отношению к юзеру у неё всёравно будет схема в виде формочек потому что сука данные без знания о том как их интерпретировать это шум. Так что понятие схемы раскрывается том уровне на котором мы рабоаем с данными. а на каком уровне с данными работает кодерок ? почему монгомразь говорит что реляционке не похуй какая схема ? потому что кодерок делегирует реляционке делать некоторую работу по поддержанию непротиворечивости данных самой бд. и до какого то момента абстракции надо информацией становятся текучими и то что монгомразь отрицает как "схему бд" но упорно делает в аппликации запрашивая из жсона поля, имена которых она ожидаем там увидеть это тоже схема, просто на уровне аппликации, и это законно является схемой потому что кодерок с ней ебётся большую часть времени

схема это тип кажется ты путаешь схему с доменом

ты почти все правильно написал, за исключениием того, что в случае key-value понятие “схемы” либо вообще не существует, либо существует только внутри твоей бизнес-логики, если тебе так удобно.

>ибо существует только внутри твоей бизнес-логики, я это и написал

например, представим себе стартап - “умный гитхаб”. Хранится не сам код, а AST по каждому файлу с кодом, то есть дерево синтаксиса, чтобы код было легко анализировать. И лежит это все в каком-нибудь хранилище типа Elasticsearch. Так вот - есть документы, есть у них ключи-айдишники и есть таймстемп их добавления в базу

ну работаешь на уровне аста - имеешь схему определяющуюся астом. поднимаешься выше/ниже значит схему идеем другую. в тех понятиях которые я описал не противоречиво

а то, что кто-то ожидает из базы определенные поля увидеть - это лишь значит, что у него либо есть общая спека, подкрепленная бизнес-логикой (+ он делает проверки на ошибки в коде), либо он упорот и таких нельзя пускать писать код

ну работаешь на уровне аста - имеешь схему определяющуюся астом. поднимаешься выше/ниже значит схему идеем другую. в тех понятиях которые я описал не противоречиво

ну так это не схема же уже, это просто какая-то абстрактная херня. Можно AST заменить на file.bmp и реализовать в коде поиск по картинкам