This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
The goal is to use lightSpeed with SQLite stored in-memory with the following scenario:
1. create migration
2. manipulate data on migrated database
According to SQLite documentation the in-memory database exists as long as connection to this database stays open. To avoid closing connections we use Connection Pooling ("Data Source=:memory:;Pooling=True;Max Pool Size=1;") but in some cases after migration we lost our connection (probably after garbage collection). |
|
|
No, there's no equivalent to ConnectionStrategy for migrations, and pooling certainly wouldn't guarantee that the connection stays open. A possible workaround would be to use the Visual Studio migrations runner to emit a SQL script to create the database. This is viable because, as it is an in-memory database, you will always be rebuilding it from the ground up so you don't need to handle different 'migrate from' versions. You could then run that SQL script during connection initialisation as part of your unit of work's connection strategy. It's not as elegant as being able to use migrations directly but it would get around the need to share a connection across multiple migrations and the unit of work. |
|
|
Thank You for Your suggestion. I solved this issue creating an empty database file and using SQLite provider's backup feature to copy it to the InMemory database. |
|
|
Thank You for Your suggestion. I solved this issue creating an empty database file and using SQLite provider's backup feature to copy it to the InMemory database. |
|