Да, именно

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

И то и то

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

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

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

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

типа foreign key?

Нет

а как?

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

так

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

так

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

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

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

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

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

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

Разве нет?

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

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

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

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

Если считать что новое поле=миграция

грубо говоря эти скрипты выполняются по порядку

накатывая все изменения на базу исторически

и тогда ты получаешь последнюю версию

без потери данных

и тогда можно обновляться с любой версии на любую нажал я npm update myapp

и получил в preinstall апдейтики

я пока так планирую

ну как вариант, но хотелось бы в более сжатом виде, так сказать для чайников :)

http://stackoverflow.com/questions/25568613/node-js-event-loop Допустим, если для чайников

Вам скорее всего не нужен, но есть такая штука как event sourcing (типа как redux на клиенте). Там достаточно просто удалить все данные, кроме ивентов и рестартануть ивенты

А так запилите коллекцию с миграциями, куда пишите последнюю версию схемы. Скрипт запуска миграций такой: взять последнюю версию из базы, взять из папки все более новые миграции и накатывать по одной

В миграцию есть смысл добавлять две команды - up и down. Если потом придётся откатывать

http://stackoverflow.com/questions/25568613/node-js-event-loop Допустим, если для чайников

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

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

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

Можешь ещё раз вопрос сформулировать?

Я, кажется, понял. Чувак, а ты знаешь как работают замыкания?

да, электрические

Я, кажется, понял. Чувак, а ты знаешь как работают замыкания?

Да, наверняка суть вопроса была в этом

Можешь ещё раз вопрос сформулировать?

вопрос в следующем - в пыхе когда приходит коннект от браузера, хедеры всякие, сам реквест, будь то гет или пост или что еще, скрипт отрабатывает, отдает результат и завершается, с полной очисткой памяти. поэтому искаропке в пыхе нет и не бывает никакого стейта, каждый раз приходится с клиента куку слать, парсить ее, сессию из файла или еще откуда таскать и прочие ужосы. в ноде все иначе, плюс коннект может не обрываться, в частности для СПАхи с кучей аякса это вообще гут. Плюс пока процесс крутится, он хранит весь стейт. Т.е. вот ты запустил node index.js допустим и доколе скрипт не завершит выполнение всех-всех-всех операций либо не крашнется, стейт сохраняется, а если мы в скрипте запустим веб-сервер, который слушает порт, то все, пока скрипт не крашнется или по CTRL-C Или как еще не отвалится, стейт хранится. При этом на порт лосятся клиенты с разных браузеров, т.е. один и тот же скрипт обслуживает кучу разных запросов. Я нутром чую, что для каждого отдельного коннекта стейт хранится отдельно, иначе это была бы вакханалия. Вопросов два - евент луп единый для всех коннектов или тоже по лупу на каждый коннект? И насколько сильно изолированы стейты, могут ли они сообщаться с ведома скрипта?

Я, кажется, понял. Чувак, а ты знаешь как работают замыкания?

есть общий стейт - это все переменные в скрипте

а есть стейт реквеста - он в обработчике

т.е. я правильно понимаю что на потоке единый стейт на все коннекты?

Я, кажется, понял. Чувак, а ты знаешь как работают замыкания?

канэшна дарагой :)

например, если ты делаешь скрипт var players = []; app.post(‘/addPlayer’, (req,res)=>{ players.push[req.body.name] }) то в players будет общий стейт

и поток один

т.е. любой коннект в потенциале может получить доступ к этому общему стейту?

Что такое стейт? Есть переменные и есть их область видимости. Обработчик запроса — функция. Всё, что было в функции, остаётся в функции.

т.е. любой коннект в потенциале может получить доступ к этому общему стейту?

да

стейт это все переменные запущенного скрипта

вообще все

Он на то и общий какбэ

понял, мерси

хотя одну штуку не догоняю я еще

вот 100 бразуеров ломятся на порт

т.е. 100 коннектов имеем

и для каждого надо сходить в бд

т.к. все асинхронно и евент луп

непойми когда что отработает