Hi,
I have a working webapi project (4.6) using entity framework code first with some code first model classes and using add-migration, update-database type of typical workflow.
I have a need to create a lighter version of the exact same service and run it on rasberry pi 2B device. I want to use the exact same code, ef model first db model classes and target sqlite to run the web service under mono on the pi.
a) Is this realistic and doable as an overall strategy?
b) Can I use the exact same db model classes and the same type of update-database migration workflow and just target a sqlite database with an alternate connection string? Does the devart driver provide complete compatibility in this regard?
c) Does the devart driver insulate me fairly well from type mismatches between sql server and slite as long as I stick to: int, string, decimal, DateTimeOffset ?
d) As long as I don't use db functions, will most of my linq statements work the same way?
e) Does one traditionally have to rewrite any of the prior code when going from sql server to slite?
Just to be clear, the sqlite version will provide an offline type of capability only on certain devices and then I will have some code for the data to sync up to the sql serve version...
Thanks
Reusing existing EF 6 db model classes (originally for sql server) with dotconnect for sqlite (on mono)
Re: Reusing existing EF 6 db model classes (originally for sql server) with dotconnect for sqlite (on mono)
We have not tested this approach. But we have received feedbacks from our users who:t316 wrote:a) Is this realistic and doable as an overall strategy?
1) used dotConnect for SQLite with Mono (ADO.NET)
2) used dotConnect providers with EF 6 under Mono: http://forums.devart.com/viewtopic.php?f=30&t=25699
We do not guarantee any compatibility. Although you can evaluate (free use during 30 days) the trial version of dotConnect for SQLite Professional Trial and send us your feedback concerning a particular problem you may encounter. We will investigate it and notify you about the result.
You can find out the EF Migrations limitations of SQLite at http://blog.devart.com/entity-framework ... ionSupport.t316 wrote:b) Can I use the exact same db model classes and the same type of update-database migration workflow and just target a sqlite database with an alternate connection string? Does the devart driver provide complete compatibility in this regard?
Please refer to https://www.devart.com/dotconnect/sqlit ... pping.html.t316 wrote:c) Does the devart driver insulate me fairly well from type mismatches between sql server and slite as long as I stick to: int, string, decimal, DateTimeOffset ?
They should work. By the way, there is a sample with the same model for different databases: http://blog.devart.com/entity-framework ... ml#Samples.t316 wrote:d) As long as I don't use db functions, will most of my linq statements work the same way?
No, he doesn't (if database specific types were not specified in the code explicitly). The int, string, decimal data types should work smoothly. The datetimeoffset pseudo type of SSDL, which corresponds to System.DateTimeOffset, is implemented in dotConnect for SQLite. Be aware that DateTimeOffset is not supported by SQLite engine natively (https://www.sqlite.org/datatype3.html), it is actually a text field within SQLite database.t316 wrote:e) Does one traditionally have to rewrite any of the prior code when going from sql server to slite?