Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SQLite: DateTime Length Fallback Of 0 Leads To Empty Column Value On Insert #349

Closed
warappa opened this issue Oct 9, 2023 · 0 comments · Fixed by #350
Closed

SQLite: DateTime Length Fallback Of 0 Leads To Empty Column Value On Insert #349

warappa opened this issue Oct 9, 2023 · 0 comments · Fixed by #350
Assignees
Labels
bug Something isn't working

Comments

@warappa
Copy link

warappa commented Oct 9, 2023

Issue

I have a SQLite database (for my integration tests). All the mapping is inferred from the EF Core mapping (no manual configuration/attributes).

When I use BulkCopy with BulkCopyOptions using UseParameters = true, a DateTime value gets written as an empty string to the SQLite database, although the DateTime value is set to a valid, non-default value.

Investigation

I debugged this and traced it back to this line

GetMaxLength() returns indeed null, fallback of 0 is used.

As far as I tested, only SQLite is affected (SQL Server and Oracle look to work fine).

Debugging

Used the debug symbols and debugged it. At the mentioned line I set the value of length to null instead of 0.
This fixed the issue for me in this debug run.

Theory

It seems for SQLite, this fallback causes Linq2db to not send anything. I guess, because in SQLite there is no DateTime type but it is represented (in my case) as TEXT, it trims the "text" to a length/size of 0 (fallback value). This leads to an empty string.

Expected

DateTime column value should not be cut down to an empty string but have a full date-time value.

Workaround

None that worked. Using UseParameters = false in BulkCopyOptions works for SQLite, but is inefficient in the real provider (Oracle).
I think in some way I can workaround it in the non-test implementation, but then the tests change the "unsuspecting" domain implementation which I dislike. So a fix would be appreciated.

Failed tries:

  • [Column(Length=50)] on property (ignored and without effect due to code mentioned above)
  • .HasMaxLength(50) in EF Core mapping (EF Core validation exception)

Info

.NET: 7.10
linq2db: 5.2.2
linq2db.EntityFramework: 7.5.0

@MaceWindu MaceWindu added the bug Something isn't working label Oct 9, 2023
@MaceWindu MaceWindu self-assigned this Oct 12, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Development

Successfully merging a pull request may close this issue.

2 participants