Потенциально не офф прошивки с более свежим андроидом. Если они существуют под нужную модель и есть навыки их ставить или кому. Но это, естественно, лечение симптомов.
Для всех возможностей termux нужен root, и с свежими версиями андроида там все больше ограничений. В посте речь именно о виртуалке, там по идее их быть не должно. По крайней мере частично.
Разный порядок аргумент создан намеренно, что-то связанное с внутренним устройством и хешированием сигнатуры функции. Сейчас вероятно не хотят ломать обратную совместимость лишний раз.
Как это понять? Не в первый раз слышу, но за собой не замечаю. Сразу пытаешься строить фразу и, иногда, зависаешь пытаясь найти нужное слово. Но вот так что бы сформулировать на родном и потом переводить, это же крайне не очевидно. Я сейчас поставил дуолинго для японского и малость страдаю когда на паре английский/японский слово находится в противоположных концах предложения. It's rice and water. Но: Gohan to mizu desu.
В Латвии можно подписать договор электронной подписью, я так и устроился на прошлую работу. Офиса в глаза не видел. Да и отдел сократили так же, звонок в тимсе, документ с электронными подписями и свободен. Правда, сейчас как-то проблема найти удаленку. Гибрид преподносят как дар богов.
Касательно "что у сущности Customer будет первичный ключ CustomerId". Предполагаю что изначальная ошибка в бойлерплейте существенно менее вероятна и будет отловлена раньше чем ошибка в логике. К тому же это все пишется однократно, а в логике используются/переписывается много кратно, с большим количеством разнообразного контекста в голове. Внешний ключ это что? Вне системы есть только int/long и.т.д. . Дальше маппер конвертирует в правильный тип. А ошибка в конвертации - начало это комментария. Неверное использования API, вообще другого рода проблема. Глобальная мысль в том что добавляются правила в которых можно ошибиться, но вероятность ниже чем ошибка без этих правил.
Изначально кажется что record struct сложный тип, чрезмерный для одного значения. Или иными словами даже в голову не пришло. Но учитывая то как доступен F# тип в C#, особой разницы уже не видно. Нет в мире идеала.
Из вне и в базе будет long. То есть контроллер принимает модель. Модель валидируется. Мапится на модель/тип на прямую. Некие действия/хождения по логике. EF: modelBuilder.Entity<TestEFInterop>()
.Property(x => x.Id)
.HasConversion<long>(); Клиенту возвращается специфичная DTO. Итого пара строчек для EF на каждое такое поле, и в маппере с/на каждую связанную DTO. Cериализатора и сваггера не касается. Да местами чуть больше возни, но и больше гарантий что что-то не то не улетит не туда.
Хорошо, нечто более продвинутое, увы не работает. Но как минимум можно создавать всякие CustomerId которым нельзя присвоить просто int или OrderId. Уж это-то компилятор шарпа не даст перепутать. Я собственно из-за это фичи и спрашивал изначально. Или такое улучшение того не стоит в масштабах проекта?
Потенциально не офф прошивки с более свежим андроидом. Если они существуют под нужную модель и есть навыки их ставить или кому. Но это, естественно, лечение симптомов.
Для всех возможностей termux нужен root, и с свежими версиями андроида там все больше ограничений.
В посте речь именно о виртуалке, там по идее их быть не должно. По крайней мере частично.
В Литву, во время, ковида, не литовцев но владельцев недвижимости - не пускали.
Можно уточнить, почему лучше?
Разный порядок аргумент создан намеренно, что-то связанное с внутренним устройством и хешированием сигнатуры функции.
Сейчас вероятно не хотят ломать обратную совместимость лишний раз.
Как это понять? Не в первый раз слышу, но за собой не замечаю.
Сразу пытаешься строить фразу и, иногда, зависаешь пытаясь найти нужное слово.
Но вот так что бы сформулировать на родном и потом переводить, это же крайне не очевидно. Я сейчас поставил дуолинго для японского и малость страдаю когда на паре английский/японский слово находится в противоположных концах предложения.
It's rice and water. Но: Gohan to mizu desu.
Да я скорее о чем-то локальном, как с картинками - SD 1.5 и сидеть генерировать потихоньку.
Сейчас как прочитаю чем и как оно делалось! Ан нет, всего-то сборник ссылок на видосики.
В Латвии можно подписать договор электронной подписью, я так и устроился на прошлую работу. Офиса в глаза не видел. Да и отдел сократили так же, звонок в тимсе, документ с электронными подписями и свободен.
Правда, сейчас как-то проблема найти удаленку. Гибрид преподносят как дар богов.
Если на то пошло то можно глянуть в эту сторону https://github.com/petersalomonsen/wasm-git
Касательно "что у сущности Customer будет первичный ключ CustomerId".
Предполагаю что изначальная ошибка в бойлерплейте существенно менее вероятна и будет отловлена раньше чем ошибка в логике.
К тому же это все пишется однократно, а в логике используются/переписывается много кратно, с большим количеством разнообразного контекста в голове.
Внешний ключ это что? Вне системы есть только int/long и.т.д. . Дальше маппер конвертирует в правильный тип. А ошибка в конвертации - начало это комментария. Неверное использования API, вообще другого рода проблема.
Глобальная мысль в том что добавляются правила в которых можно ошибиться, но вероятность ниже чем ошибка без этих правил.
Изначально кажется что record struct сложный тип, чрезмерный для одного значения. Или иными словами даже в голову не пришло.
Но учитывая то как доступен F# тип в C#, особой разницы уже не видно.
Нет в мире идеала.
Из вне и в базе будет long.
То есть контроллер принимает модель.
Модель валидируется.
Мапится на модель/тип на прямую.
Некие действия/хождения по логике.
EF:
modelBuilder.Entity<TestEFInterop>() .Property(x => x.Id) .HasConversion<long>();Клиенту возвращается специфичная DTO.
Итого пара строчек для EF на каждое такое поле, и в маппере с/на каждую связанную DTO.
Cериализатора и сваггера не касается.
Да местами чуть больше возни, но и больше гарантий что что-то не то не улетит не туда.
Хорошо, нечто более продвинутое, увы не работает.
Но как минимум можно создавать всякие CustomerId которым нельзя присвоить просто int или OrderId. Уж это-то компилятор шарпа не даст перепутать.
Я собственно из-за это фичи и спрашивал изначально. Или такое улучшение того не стоит в масштабах проекта?
А почему нельзя рядом с основным С# кодом, создать F# проект. И в нем создать типы, а в C# использовать.
Как-то я ничего не смог нагуглить про такой трюк, а в официальном дискорде по C#, мой вопрос то ли пропустили, то ли проигнорировали.