Entityframework.docs: You can't have computed datetime columns.

[speciesunknown]

The premise of this documentation is that SQLite behaves like a relational database but its more or less guaranteed that it doesn't behave like the one you are using in production. I was forced to abandon sqlite as a test analogue because you can't have computed datetime columns.

There are multiple limitations which make SQLite in memory non viable:
https://docs.microsoft.com/en-us/ef/core/providers/sqlite/limitations

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: e4f7b56f-7f91-2f15-1fb6-4f481e97534f
• Version Independent ID: 6d9c65c6-f159-b234-48fd-f25da05f0f32
• Content: Testing with SQLite - EF Core
• Content Source: entity-framework/core/miscellaneous/testing/sqlite.md
• Product: entity-framework
• GitHub Login: @rowanmiller
• Microsoft Alias: divega

[ajcvickers]

Thanks for the feedback. Whether or not SQLite works for you or not depends what you are trying to test. If the code is largely database agnostic and just needs to get data from somewhere, then in-memory is a good choice. If the code depends on relational concepts, like transactions, but is largely agnostic to the specific relational database engine, then SQLite in-memory might be better. If the code depends on specific functionality of the database engine, then the only option is to test with that specific engine.

[speciesunknown]

Thanks for the reply. That's a good statement there, I would say it needs to be prominent in the introduction of the document. I think the crux of the issue is that sqlite in memory is only a good test analogue if the system is already using it.

[bricelam]

Updated the docs to list more known limitations.

Also, you could use a non-computed column with a trigger to emulate computed columns in SQL Server:

CREATE TRIGGER SetUpdatedDate
AFTER UPDATE ON MyTable
BEGIN
    UPDATE MyTable
    SET UpdatedDate = CURRENT_TIMESTAMP
    WHERE rowid = NEW.rowid;
END