OneScript.Web
OneScript.Web copied to clipboard
EvilBeaver
База данных в памяти (SQLite)
Использование в памяти невозможно, так как при вызовах методов происходит открытие базы, в случаи с инменори это обозначает создание базы.
Есть еще проблема, после решения вопроса с инмемори все таки не получается обратиться к базе из контроллера. Т.е все действия в модуле в момент запуска проходят, но при обращении с контроллера к базе, идет обращение как будто к другому инстансу БД
т.е из модуля в DataSourse = "", а вот при вызове из контроллера, там уже указано ":memory:"
т.е из модуля в DataSourse = "", а вот при вызове из контроллера, там уже указано ":memory:"
в общем пришлось сначала сделать вызов инициализации базы из контроллера, а не при старте приложения, но это как-то не очень
@EvilBeaver @dmpas
подскажите как победить проблему с инициализацией базы при старте и отсутствия ее при дальнейшего вызова из контроллеров
К базе обращаться в ПриНачалеРаботыСистемы, когда еще ни один контроллер не принимает вызовы.
Перенес создание базы в основной модуль, такая же ситуация, при обращении из контроллера пишет no such table
В общем разница в DataSource при инициализации из ПриНачалеРаботыСистемы и обращения из контроллера
ПриНачалеРаботыСистемы:
Контроллер:
Пробовал "Data Source=:memory:;Mode=Memory;Cache=Shared"
пока безрезультатно
Я тоже порядком времени убил, у меня заработало только с FileUri. Надо понять, почему он не работает в ос.веб.
FileUri вроде как из Microsoft.Data.Sqlite, точнее из SQLitePCLRaw, версии >= 1.08
а в ос.веб Microsoft.Data.Sqlite был впоследствии заменен на ранее уже применяемый Microsoft.EntityFrameworkCore
Чтобы было понимание: механики работы с базой данных считай отсутствуют. Нужна помощь в реализации и построении идеологического концепта, который мы предложим сообществу.
@EvilBeaver есть набросок концепции?
Изначально думалось, что будет как в 1С - одна ИБ и в ней некий ORM Потом @nixel2007 придумал библиотеку entity. Она ложится на изначальную идею, но ей нужен "адаптер" к веб-движку. И требования к такому адаптеру
Полагаю, что из "требований к адаптеру" и можно сформулировать то, что должен уметь движок.
Адаптер-то уже есть. Там нужно пару строк подправить, чтобы он научился работать в вебе (руки не доходят, как обычно). И реализовать lastInsertedId, чтобы не велосипедить пакетные запросы
Адаптер-то уже есть. Там нужно пару строк подправить, чтобы он научился работать в вебе (руки не доходят, как обычно). И реализовать lastInsertedId, чтобы не велосипедить пакетные запросы
Вот не смог найти ни у @nixel2007 ни у @asosnoviy в репах
чтобы не велосипедить пакетные запросы
А что там про пакетные запросы? Просто lastId есть далеко не во всех СУБД
@pallid локально в стэшах :/
@EvilBeaver в субд, где нет lastId он обычно возвращается как результат инсерта. Но если и там нет, то да, придётся велосипедить, правда нет уверенности, что на всех типах ключей это получится
@nixel2007 вот я и говорю, что получение последнего ИД это тоже к адаптеру entity вопрос, а не к движку. А движок должен дать что-то более универсальное (например, результат последнего инсерта) Короче, тут думать надо, но задача решаемая.
@EvilBeaver а движку вообще не нужен ид последней записи. Он нужен чтобы заполнить ид в сущности, предоставить этот ид - задача адаптера, а как он будет это делать - это уже его головная боль.
адаптер к sqlite (который использует sql из библиотеки) берет его из lastInstertedId, которая у @ret-phoenix реализован для sqlite. если кто-то возьмется делать адаптер для постгреса, то надо либо научить библиотеку sql возвращать LII для постгреса, либо велосипедить пакетный запрос (либо еще внимательнее курить документацию, авось это есть :) ).
@EvilBeaver что-то типа Insert value to table; Select max(id) from table;
@ret-Phoenix ну вот и получается, что каждая СУБД имеет свой набор костылей. Я пытался гуглить по MSSQL и вроде бы там вообще нет надежного средства, только условно возможные...
Оставлю work around: Если стартовать в docker compose - можно разместить базу в tmpfs и получится "почти инмемори".
