Я вас понял. У нас есть отведенное для тестирования время и в конце спринта всё вливается в master, либо спринт проливается. Если нужна доработка создается отдельная фикс-миграция. Проблем с EF не наблюдаем.
Раз у вас принятно вливать по отдельности, наверное, EF не самый удачный выбор.
Но он делает так не потому что он "плохой", а потому что такой подход дает гарантию не сломать БД при мерже.
А как вы решаете такую проблему?
Фича в девелопе готова к мержу в мастер, но в develop'е уже есть другие миграции, которые пока не готовы и связанны с вашей?
Я это и имел ввиду, т.к. timestamp зашит в имени.
Но как это решает проблему?
Сэм начал разработку 10го числа, закомитил 20го, Боб начал 15го, закомитил 16го. в итоге сначала выполняетя миграция от 15го числа, а потом от 10го.
Или я что-то недопонял?
Имхо, если вы так делаете, то тут и с EF и без будет кошмар.
Обычно разработка ведется в фиче бранче, потом заливается в develop, а develop вливают в master fast-forward'ом и проблем быть не должно
Это не решает проблему, т.к. timestamp миграции 2го комита может раньше timespamp'а миграции 1го, а миграции должны выполняться последовательно, иначе будет undefined behavior :)
У меня другой совет Сэмам и Бобам: раз уж сидите на дотнете, используйте EF-миграции.
Перед комитом с миграцией, заливайте в свой фиче-бран последние изменения и если там есть новая миграция, просто перегенерируйте свою. Это делается несложным скриптом:
1 Update-Database -TargetMigration "before"
2 удаляем свою миграцию
3 Add-Migration "myNewMigration"
Тогда не надо будет договариваться, менять числа на сервере, ставить хуки, вы не будете блокировать друг друга и если миграции затрагивают одни и те же таблицы, у вас будет возможность решить конфликты.
P.P.S.
Еще можно "огородить" работу с БД отдельным интерфейсом/сервисом и делегировать это специально выделенному человеку. Остальные будут работать с ней только через интерфейс/RPC используя временные "затычки".
Или банально делать более мелкие комиты. Проблема останется, но разруливать мелкие конфлиты гораздо проще и экономнее для нервной системы :)
Только синтаксис C# не позволит писать так в аттрибутах.
Как это не позволяет?!
public class Sensor
{
public SensorType Type { get; set; }
[Number(Type = SensorType.Temperature, Min = 200, Max = 600, Force = 273)]
[Number(Type = SensorType.Voltage, Min = -400, Max = 400, Force = 0)]
public decimal Value { get; set; }
}
public enum SensorType
{
Temperature,
Voltage
}
[AttributeUsage(AttributeTargets.All, AllowMultiple = true)]
class NumberAttribute : Attribute
{
public SensorType Type { get; set; }
public int Min { get; set; }
public int Max { get; set; }
public int Force { get; set; }
}
Это чтобы вам было
Я уже молчу про то, что ограничили возможности webRequest API, который используется блокировщиками для фильтрации рекламы и трекеров.
Этот факт, конечно же, в статье не упоминается.
Довольно цинично получилось.
Поменялось
Это курсовая работа четверокурсника? Угадал? :)
Я вас понял. У нас есть отведенное для тестирования время и в конце спринта всё вливается в master, либо спринт проливается. Если нужна доработка создается отдельная фикс-миграция. Проблем с EF не наблюдаем.
Раз у вас принятно вливать по отдельности, наверное, EF не самый удачный выбор.
Но он делает так не потому что он "плохой", а потому что такой подход дает гарантию не сломать БД при мерже.
А как вы решаете такую проблему?
Фича в девелопе готова к мержу в мастер, но в develop'е уже есть другие миграции, которые пока не готовы и связанны с вашей?
Я это и имел ввиду, т.к. timestamp зашит в имени.
Но как это решает проблему?
Сэм начал разработку 10го числа, закомитил 20го, Боб начал 15го, закомитил 16го. в итоге сначала выполняетя миграция от 15го числа, а потом от 10го.
Или я что-то недопонял?
Имхо, если вы так делаете, то тут и с EF и без будет кошмар.
Обычно разработка ведется в фиче бранче, потом заливается в develop, а develop вливают в master fast-forward'ом и проблем быть не должно
Это не решает проблему, т.к. timestamp миграции 2го комита может раньше timespamp'а миграции 1го, а миграции должны выполняться последовательно, иначе будет undefined behavior :)
У меня другой совет Сэмам и Бобам: раз уж сидите на дотнете, используйте EF-миграции.
Перед комитом с миграцией, заливайте в свой фиче-бран последние изменения и если там есть новая миграция, просто перегенерируйте свою. Это делается несложным скриптом:
1 Update-Database -TargetMigration "before"
2 удаляем свою миграцию
3 Add-Migration "myNewMigration"
Тогда не надо будет договариваться, менять числа на сервере, ставить хуки, вы не будете блокировать друг друга и если миграции затрагивают одни и те же таблицы, у вас будет возможность решить конфликты.
P.S. доки по теме: https://docs.microsoft.com/ru-ru/ef/ef6/modeling/code-first/migrations/teams
P.P.S.
Еще можно "огородить" работу с БД отдельным интерфейсом/сервисом и делегировать это специально выделенному человеку. Остальные будут работать с ней только через интерфейс/RPC используя временные "затычки".
Или банально делать более мелкие комиты. Проблема останется, но разруливать мелкие конфлиты гораздо проще и экономнее для нервной системы :)
Но таблице указано Mono 6.6.0 и кортежи есть в 7ой версии
Ну и для красоты, замените
на
Чем мы хуже гошников, в конце-то концов? :)
Именно это и хотел замерить автор
Да. Стоит дважды подумать, нужна ли такая экономия на спичках.
Тем не менее это решает проблему автора.
В вашем примере можно:
На моей машине время выполнения упало с 19 сек. до 2ух, практически сравнявшись с синхронной версией.
Кстати, даже банальное:
дает выигрыш в 2 раза
В некоторых системах счисления может получиться не 4, а 10 или даже 11 :)
Любой тьюринг-полный язык позволяет писать код любой сложности
Откуда этот термин? Вы сами его придумали?
Возможно ошибаюсь, но разве TPL Dataflow не аналог?
Забавно, что статья называется "Динамическое аспектно-ориентированное", но что именно?
Как это не позволяет?!
Читаем определение на Википедии:
The Domain Name System (DNS) is a hierarchical and decentralized naming system for computers
Дополню ссылкой на SO