Хорошая статья, но на мой взгляд не хватает для пояснения элементарной вещи. Глядя на последовательность 00001001, которую обычно мы интерпретируем слева направо, нужно пояснить, где тут старший байт, а где младший. Я бы в перевод добавил картинку как эта https://uynguyen.github.io/2018/04/30/Big-Endian-vs-Little-Endian/
Связь электричества клеток и морфогенез известная много десятилетий идея. И это одна из частей мозаики морфогенеза. Работа Майкла Левина хорошая, но интерпретация абсолютно спорная.
Газпром убыточная компания. Чудо тут не будет. Увеличение численности почти 2 раза за последние годы и снижение прибыли, с уверенным выплатами дивидендов, плюс льготы по налогами — прямое разорение госкорпорацией России. Никакой дата сайнс тут не поможет.
>>> P.S. Откатить уже подтвержденную транзакцию вовсе не тривиальная задача, если транзакция затронула несколько таблиц в базе.
Ну это да. Скорее всего тут надо задуматься о полной реорганизации системы, так как в тяжелом и запущенном случае если хаос доминирует, то никакие транзакции реализованы быть не могут.
Применительно к модели КТР, когда упал второй commit в записи транзакции фиксируем ошибку. И тут возможны несколько вариантов которые очеквидны, но которые я не детализировал.
1. Самый правильный вариант — откатить всю транзакцию. В составе КТР вам нужен механизм отката изменений по первому commit. Соответственно, как только есть ошибка, срабатывает этот механизм, вы используете данные до изменения (ну вы где-то их храните) и возвращаете все в первоначальный вид в первой базе. И удалаете всю транзакцию.
2. Второй вариант — повторы — это указано в модели. Просто накруичваете N повоторов по второму commit. Если исчерпано кол-во поторов — - восстановление данных по первому комиту и откат распределнной транзакции. Вариант с повторами — проблематичный.
В модели КТР — не рассмотрены механизмы «отката» в связи с вашим случаем. Но принципиально их может быть два основных:
1. Вы сохраняете изменяемые данные по ВСЕМ базам и в вашем случае возвращаете все на место. Не важно сколько баз было. Лучше всего сделать аналогичную таблицу/ы и туда копировать запись предполагаемую на изменение.
2. Когда есть возможность, использовать спец. поле RecordState добавляемое в каждую таблицу изменяемую транзакцией. У RecordState тип данных bit/boolean/int, где 0 = not ready 1= ready. Ставите 1 когда все ок по комиту. Если нет то 0 так и остается и записи позже просто удаляете. Но система использующая данные таблицы должна игнорировать записи с RecordState = 0. Этот вариант требует доработки системы и он сложнее.
Вы написали "… нежели преобразование целого урла к какому-то виду."
Урл преобразуется на стороне сервера, этот код не передается на сервер можно проверить профайлером SQL.
Душевно благодарю на указанную неточность! Исправлено, с добавлением расширенного примера использования асинхронного запроса из репозитория бизнес-логики в компонент представления ASP .NET Core. В репозитории присуствует синхронный и асинхронный варианты методов получения данных. Еще раз спасибо, за просмотр моей статьи!
Думаю, что нет. Ключевым моментом является использование AsEnumerable() так как предполагается получение отфильтрованных записей только на чтение.
Соглашусь, что StandardizeUrl(blog.Url) может быть выполнено позже когда найдены все записи по условию .Contains(«dotnet»).
Работает как часы. Спасибо!
Тут все относительно... Для кого-то и рак - это рыба. )))
ERROR: отношение "public.users_pkey" не существует
ERROR: отношение "partners" не существует
Я думаю реальность должна быть рекурсивной и соответственно вечной.
Точно ))) https://www.scientificamerican.com/article/confirmed-we-live-in-a-simulation/
Хорошая статья, но на мой взгляд не хватает для пояснения элементарной вещи. Глядя на последовательность 00001001, которую обычно мы интерпретируем слева направо, нужно пояснить, где тут старший байт, а где младший. Я бы в перевод добавил картинку как эта https://uynguyen.github.io/2018/04/30/Big-Endian-vs-Little-Endian/
Связь электричества клеток и морфогенез известная много десятилетий идея. И это одна из частей мозаики морфогенеза. Работа Майкла Левина хорошая, но интерпретация абсолютно спорная.
1)сделать метод async, чтобы избавиться от wait
Конечно, на усмотрение разработчика
2)не собирать xml как интерполяцию, т.к. если у вас в тексте будет например кавычка или символ <, xml будет невалидна
Ну тут все жестко, другой код и не приходит, кавычки исключены, все вшито в софт модема
Смело можете доработать и запускать платный сервис по отправке СМС! )))
Газпром убыточная компания. Чудо тут не будет. Увеличение численности почти 2 раза за последние годы и снижение прибыли, с уверенным выплатами дивидендов, плюс льготы по налогами — прямое разорение госкорпорацией России. Никакой дата сайнс тут не поможет.
Что за бред.
Ну это да. Скорее всего тут надо задуматься о полной реорганизации системы, так как в тяжелом и запущенном случае если хаос доминирует, то никакие транзакции реализованы быть не могут.
Применительно к модели КТР, когда упал второй commit в записи транзакции фиксируем ошибку. И тут возможны несколько вариантов которые очеквидны, но которые я не детализировал.
1. Самый правильный вариант — откатить всю транзакцию. В составе КТР вам нужен механизм отката изменений по первому commit. Соответственно, как только есть ошибка, срабатывает этот механизм, вы используете данные до изменения (ну вы где-то их храните) и возвращаете все в первоначальный вид в первой базе. И удалаете всю транзакцию.
2. Второй вариант — повторы — это указано в модели. Просто накруичваете N повоторов по второму commit. Если исчерпано кол-во поторов — - восстановление данных по первому комиту и откат распределнной транзакции. Вариант с повторами — проблематичный.
В модели КТР — не рассмотрены механизмы «отката» в связи с вашим случаем. Но принципиально их может быть два основных:
1. Вы сохраняете изменяемые данные по ВСЕМ базам и в вашем случае возвращаете все на место. Не важно сколько баз было. Лучше всего сделать аналогичную таблицу/ы и туда копировать запись предполагаемую на изменение.
2. Когда есть возможность, использовать спец. поле RecordState добавляемое в каждую таблицу изменяемую транзакцией. У RecordState тип данных bit/boolean/int, где 0 = not ready 1= ready. Ставите 1 когда все ок по комиту. Если нет то 0 так и остается и записи позже просто удаляете. Но система использующая данные таблицы должна игнорировать записи с RecordState = 0. Этот вариант требует доработки системы и он сложнее.
Надеюсь, я смог ответить на ваш вопрос.
Урл преобразуется на стороне сервера, этот код не передается на сервер можно проверить профайлером SQL.
Соглашусь, что StandardizeUrl(blog.Url) может быть выполнено позже когда найдены все записи по условию .Contains(«dotnet»).