Здравствуйте, ionoy, Вы писали:

Былобы прикольно обновление без отключения пользователей

Здравствуйте, ionoy, Вы писали:

VD>>Подход "от модели" мне тоже больше нравится. Но у него есть один минус. Тяжело организовать эволюционный процесс развития имеющихся БД.
I>Почему тяжело? Обновлять базу данных "вперёд" как раз легко. Насчёт отката не уверен, никогда не приходилось.

На словах — легко. А когда погрузишься в проблему, то поймешь, что все очень сложно.

Там основная проблема — сохранность данных и возможность безболезненно переключаться между новыми и старыми версиями. В решении из РоР (аналог которому сделал Зива) проблема решается ручным написанием миграционных скриптов. В них описывается как будут меняться данные.

Здравствуйте, Аноним, Вы писали:
А>Былобы прикольно обновление без отключения пользователей
Отключение от чего?

Здравствуйте, VladD2, Вы писали:

VD>Там основная проблема — сохранность данных и возможность безболезненно переключаться между новыми и старыми версиями. В решении из РоР (аналог которому сделал Зива) проблема решается ручным написанием миграционных скриптов. В них описывается как будут меняться данные.
Ну я же говорю, вперёд легко мигрировать, данные всё сохраняются. С откатом назад будет больше проблем, но ненамного. Естественно удалятся данные, для которых больше нет таблиц/полей.

Здравствуйте, ionoy, Вы писали:

I>Ну я же говорю, вперёд легко мигрировать, данные всё сохраняются.

Далеко не все. Поменял имя колонки/таблицы — приехали. Разделил таблицу на две — тоже.

Здравствуйте, ionoy, Вы писали:

I>Ну я же говорю, вперёд легко мигрировать, данные всё сохраняются. С откатом назад будет больше проблем, но ненамного. Естественно удалятся данные, для которых больше нет таблиц/полей.
Будет круто если они не будут удаляться. И тогда можно будет менять версии БД не теряя данные.

Для этого нужно создать довольно хитрый ДСЛ.
Он будт состоять из двух частей.
1)Описание данных.
2)Описание миграций.

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

database MyDB.Version1
  table Users
    pk id : int;
       FirstName : string;
       LastName : string;
  end
end

database MyDB.Version2
  table Users
    pk id : int;
       FirstName : string;
       LastName : string;
       FullName : string;
  end
end

migration MyDB.Version1 to MyDB.Version2
  lense users1 : MyDB.Version1.Users <-> users2 : MyDB.Version2.Users
    $"$(users2.FirstName) $(users2.LastName)" -> users2.FullName;
  end
end

Теперь при преобразовании из версии 1 в версию 2 у нас поле FullName будет заполнено на основе FirstName и LastName.
При обратном преобразовании будет создана таблица, в которую будут сложены значения поля FullName.
Если при этом при работе с версией 1 мы добавим пользователей, то при миграции на версию 2 мы восстановим сохраненные данные для тех пользователей что успели побывать в версии 2. И сгенерируем только для тех, что были добавлены в версии 1.

Здравствуйте, VladD2, Вы писали:
I>>Ну я же говорю, вперёд легко мигрировать, данные всё сохраняются.
VD>Далеко не все. Поменял имя колонки/таблицы — приехали. Разделил таблицу на две — тоже.

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

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, ionoy, Вы писали:

I>>Ну я же говорю, вперёд легко мигрировать, данные всё сохраняются. С откатом назад будет больше проблем, но ненамного. Естественно удалятся данные, для которых больше нет таблиц/полей.
WH>Будет круто если они не будут удаляться. И тогда можно будет менять версии БД не теряя данные.

Сейчас почитал, они не удаляются. Поддерживаются только новые таблицы/колонки, именно для того, чтобы не терять данные. Тем более, что одной базой данных может пользоваться несколько систем с разными требованиями.

WH>Для этого нужно создать довольно хитрый ДСЛ.
WH>Он будт состоять из двух частей.
WH>1)Описание данных.
WH>2)Описание миграций.

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

WH>migration MyDB.Version1 to MyDB.Version2
WH> lense users1 : MyDB.Version1.Users <-> users2 : MyDB.Version2.Users
WH> $"$(users2.FirstName) $(users2.LastName)" -> users2.FullName;
WH> end
WH>end
WH>[/nemerle]
WH>Теперь при преобразовании из версии 1 в версию 2 у нас поле FullName будет заполнено на основе FirstName и LastName.

Если бы миграции состояли только из таких выражений, то может быть было бы легче.

Здравствуйте, WolfHound, Вы писали:

database MyDB.Version1
  table Users
    pk id : int;
       FirstName : string;
       LastName : string;
  end
end

database MyDB.Version2
  table Users
    pk id : int;
       FirstName : string;
       LastName : string;
       FullName : string;
  end
end

migration MyDB.Version1 to MyDB.Version2
  lense users1 : MyDB.Version1.Users <-> users2 : MyDB.Version2.Users
    $"$(users2.FirstName) $(users2.LastName)" -> users2.FullName;
  end
end

Как минимум надо отказаться от id
Кроме того

database MyDB.Version1
  table Users
       FirstName : string;
       LastName : string;
  end
end

database MyDB.Version2
  table Users
       FirstName : string;
       LastName : string;
  //     FullName : string{new {FirstName+LastName}}  //если создаеться новый
  //     FullName : string{get {FirstName+LastName}}  //если виртуальное поле
  end
end

// в сложном случае
migration MyDB.Version1 to MyDB.Version2
  lense users1 : MyDB.Version1.Users <-> users2 : MyDB.Version2.Users
    $"$(users2.FirstName) $(users2.LastName)" -> users2.FullName;
  end
end

в простых случаях создавать явный слой миграции не надо. Система должна предусматривать следующие случаи без миграции. Добавление поля и заполнение на основе существующих данных. Выделение части таблицы в подтаблицу.
На ни приходиться 50% изменений.

Здравствуйте, WolfHound, Вы писали:

VD>>Лучше сколотить команду которой интересен весь этот энтерпрайз и доделав твой движок взяться за поддержку БД.
WH>А еще лучше скооперироваться с IT'ом. И сделать крутой BLT для немерла.

BLT и так есть. Тут речь о несколько другом. Речь о чем-то вроде миграций для РоР. Фиче позволяющей создавать и развивать БД.

Здравствуйте, Аноним, Вы писали:

А>Былобы прикольно обновление без отключения пользователей

+1 Будет над чем по ржать.

Здравствуйте, ionoy, Вы писали:

VD>>Далеко не все. Поменял имя колонки/таблицы — приехали. Разделил таблицу на две — тоже.

I>Да, без миграций такое не сделать.

Сделать можно. Но нужно не мало потрудиться/поломать голову.

I>Но честно говоря мне совершенно не понравилось работать с миграциями. Слишком много телодвижений для, казалось бы, простых изменений.

+1

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Аноним, Вы писали:

А>>Былобы прикольно обновление без отключения пользователей

VD>+1 Будет над чем по ржать.

В 1с сейчас так. (8.3 серверный вариант)

Здравствуйте, ionoy, Вы писали:

I>Есть какие-то идеи как это решить?

Компилять все с исходников!

Здравствуйте, VladD2, Вы писали:

VD>Компилять все с исходников!

Это мысль. Надо выяснить, умеет ли nuget делать пакеты из проектов с исходным кодом. Потому, что подключать проект с исходниками руками удовольствие ниже среднего.

Здравствуйте, Ziaw, Вы писали:
Z>Это мысль. Надо выяснить, умеет ли nuget делать пакеты из проектов с исходным кодом. Потому, что подключать проект с исходниками руками удовольствие ниже среднего.

А Nemerle.dll и Nemerle.Compiler.dll тоже компилять? Не будет конфликтов?

Здравствуйте, ionoy, Вы писали:

Предлагаю вообще изменить систему.

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

Далее все опциональные пакеты которые идут в установщике вынести в NuGet.
Установщик должен содержать только минимальный набор компилятор (поддержка C# и другие необходимые вещи) + интеграция.
Остальное пусть идет из NuGet, заодно это добавит версионность для библиотек.

Кроме того увеличит присутствие Nemerle в NuGet

Здравствуйте, _NN_, Вы писали:

_NN>Во первых участить сборки компилятора Nemerle.
_NN>Вместо стабильной версии раз в год как сейчас, каждый месяц-два выпускать бета версии, а стабильные раз в 3 месяца например.

Они и так частые. Ночные.

_NN>Далее все опциональные пакеты которые идут в установщике вынести в NuGet.
_NN>Установщик должен содержать только минимальный набор компилятор (поддержка C# и другие необходимые вещи) + интеграция.
_NN>Остальное пусть идет из NuGet, заодно это добавит версионность для библиотек.

И для какой версии предлагаешь собирать Nemerle.Web?


_NN>Кроме того увеличит присутствие Nemerle в NuGet

Чересчур увеличит.

Здравствуйте, Ziaw, Вы писали:

Z>Здравствуйте, _NN_, Вы писали:

_NN>>Во первых участить сборки компилятора Nemerle.
_NN>>Вместо стабильной версии раз в год как сейчас, каждый месяц-два выпускать бета версии, а стабильные раз в 3 месяца например.

Z>Они и так частые. Ночные.
Я про стабильные, их нужно чаще выкладывать.

_NN>>Далее все опциональные пакеты которые идут в установщике вынести в NuGet.
_NN>>Установщик должен содержать только минимальный набор компилятор (поддержка C# и другие необходимые вещи) + интеграция.
_NN>>Остальное пусть идет из NuGet, заодно это добавит версионность для библиотек.

Z>И для какой версии предлагаешь собирать Nemerle.Web?
Для последней стабильной.
Можно для 2-х последних стабильных версий например, хотя в этом я не вижу смысла.

Если бы фреймворк обновлялся часто, была бы точно такая же проблема.
Хотя вот, даже сегодня если выпускаешь библиотеку тебе нужно собирать 3 а то и больше версий под разные версии фреймворков.

Здравствуйте, _NN_, Вы писали:

Z>>И для какой версии предлагаешь собирать Nemerle.Web?
_NN>Для последней стабильной.
_NN>Можно для 2-х последних стабильных версий например, хотя в этом я не вижу смысла.

То есть каждый автор должен апдейтить пакет каждые месяц-два?