SQLite DbCommand disposing (disconnecting)

Mar 12, 2015 at 8:31 PM
(continuing from related posts in other discussions)

Ivan,
About DbModelUpdateManager - good catch, fixed it. Now added unit test, but instead of deleting file I rename it and then rename it back (to avoid breaking other tests).
      //Testing that SQLite DbCommand is disconnected - this releases server-side resources
      if(SetupHelper.ServerType == DbServerType.Sqlite) {
        session = app.OpenSession();
        var fileName = "VitaBooksSQLite.db";
        var xfileName = "X_VitaBooksSQLite.db";
        Assert.IsTrue(System.IO.File.Exists(fileName));
        if(File.Exists(xfileName))
          File.Delete(xfileName); //in case file is left from previous failure
        File.Move(fileName, xfileName); //using Move to rename the file
        File.Move(xfileName, fileName); //rename back
        var newUser = session.NewUser("testUser", UserType.Customer);
        session.SaveChanges();
        File.Move(fileName, xfileName); //rename
        File.Move(xfileName, fileName); //rename back
      }
now everything seems to working fine, ran it multiple times in different modes. Will push the fix over the weekend.
Roman
Mar 12, 2015 at 9:06 PM
Great, many thanks!
Mar 16, 2015 at 10:14 AM
I updated to the latest version and noticed that the TestSqliteStatementFinalization test is commented out - why? It seems to be working.

I even noticed that there is no longer any need to override SQLiteDbDriver.CommandExecuted because it seems you've taken care to always disconnect the command after executing it.
Mar 16, 2015 at 5:34 PM
test method is commented because it is SQLite-specific, it is a bug-fix kinda test, no need to run it every time, better to not show up in test list for other servers. So it is commented out, but ready to be used at any moment.
As for override of CommandExecuted - yes, I tried to implement general solution that is not SQLite specific, and it seems to be working
Mar 17, 2015 at 7:03 AM
But it would be good if the test gets run before you make releases, to make sure the problem hasn't reappeared.
Commenting it out doesn't seem very convenient for that purpose, maybe marking it with Ignore or some conditional define would be a better idea.
Mar 17, 2015 at 7:18 AM
There's actually a new test method in extended test project, TestBugFixes, that contains the test for this feature. I am simply not sure where this will end up. Using Ignore - not very good, the test still appears in the list, with yellow icon, and a big distraction. Maybe the best is some generic test method with a bunch of very specific tests like this one - and method might be TestBugFixes
Mar 17, 2015 at 7:55 AM
Ah, I see, so the test is active after all, that's good. A TestBugFixes method sounds good for now, if the cases get too many one day I guess they'd be better moved to a whole new project of regression tests.