Так чатик. К вам вопрос. Пишется библиотека для WebAuthn. Дошло дело

до включенных батареек. А именно: реализация стораджа.

Условно чтобы конечный пользователь библиотеки написал services.AddWebAuthnMsSql(connStr) и у него всё поехало.

И вот у меня вопрос. А как вам лично было бы удобнее работать с миграциями?
1) Готовый пакет, скажем Lib.MsSql.Migrations DbContext’ом внутри под вашу конкретную базу и экстеншоном к хосту, написать host.ApplyWebauthnMigrations и создалась база с таблицами.
2) Готовый пакет Lib.MsSql.Migrations, у которого из зависимостей только ADO драйвер под конкретную базу и метод «накатить схему». Ну т.е. никакой истории миграций и всего остального.
3) «Я сам знаю как лучше, дай мне голый SQL, я дальше разберусь». Условно SQL в Readme.md под конкретный сторадж.

Либо какой-то альтернативный вариант.

это ты про миграции, которые накатывались бы в билд тайме?

Хоть в билд, хоть в рантайм, ап ту ю

меня как юзера рантайм миграции либ мало волнуют. Я вам выдаю коннекшн стринг и тип БД, пускай либа сама справится со своими миграциями в рантайме. Но я в целом не особо любитель накатывать в рантайме, поэтому я бы хотел накатить в init container, а для этого мне нужна msbuild таска или чот такое

Только подразумевается что ты ставишь одну конкретную реализацию и её юзаешь.

ну я говорю .AddYobaWebAuthN(opts -> opts.DbType = "postgres" opts.ConnString = "..." ) а ты уж там разберись как на неё накатить!

В противном случае у тебя абсолютно всё что есть внутри - на интерфейсах, все public методы виртуальные. Можешь собрать любую конструкцию

Я думаю, что норм сделать 1 и 3. 1 вариант можно будет юзать как из приложения, так и из отдельного проекта. 3 для любителей миграции схем держать в sql файлах

Имхо лучше дай SQL, а кому надо — завернут его в свою либу с миграциями, и им станет норм. Тебе меньше сношаться, и юзерам тоже (я вот, например, хз, как накатить несколько наборов миграций на разные датаконтексты и всё такое сразу разом на стартапе, и уж тем более на паблише или когда там ещё людям в голову взбредёт это делать). Если по мере развития либы будут апдейты схемы — то можно их мини-патчами выпускать вместе с релиз ноутами, а интеграция с какими-нибудь там EFCore'ными или даже флюент миграциями будет вечным источником попоболи для тебя. В данном случае, имхо, лучше эту попоболь переложить на юзеров.

у меня в ближайшем будущем базы все nosql, так что хотелось бы инструкций как такую либу к nosql подрубать и как оно будет между версиями работать

Тебе просто нужен другой сторадж. Я так понимаю, в либе будет интерфейс стореджа, и (потенциально) несколько искоробочных реализаций — под разные СУБД там или под БД провайдеры. Для NoSQL просто пишется ещё один сторедж, ну или же берётся искоробочный, если у тебя популярный NoSQL типа Монги.

ну вот я на это и надеюсь) чтобы либа как-либо не предполагала sql сторадж под собой

Там модель для хранилища развязана от основных моделей. За исключением енамов - они переиспользуются. В целом можно сконвертировать в JSON или любой другой формат внутри реализации интерфейса хранилища и сложить в любую бд

Если ты можешь хранить в nosql сразу, лучше так и сделать

Там 4 интерфейса где на вход/выход либо POCO, либо строки/массивы байт

Лучше кому?

а покажи)

Лучше всем, сделать из sql nosql - изи, а вот наоборот - довольно трудно

А это чуть попозже. Надо репозиторий на другую оргу перенести.

кстати, насчёт энамов - в базе лучше их интами не хранить, а ориентироваться на string based enums

IHueMoeStorage + одна реализация на ef core для примера. Куда я твою отдельную базу деплоить буду? В свою же от сервиса авторизации, чтобы ты в минорном апдейте либы в миграцию добавил drop users; ?

сделать пачку интерфейсов типа IUserRepository и пусть юзер ебется с тем как он хочет их хранить

Как он даст SQL, если у него много баз поддерживается и возможно будет ещё больше

Он те выше уже дал SQL.