Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upMicrosoft.Data.Sqlite: Add Default Timeout connection string keyword #23091
Conversation
nmichels
commented
Oct 24, 2020
|
|
LGTM |
| @@ -275,6 +275,11 @@ public override void Open() | |||
| this.ExecuteNonQuery("PRAGMA recursive_triggers = 1;"); | |||
| } | |||
|
|
|||
| if (ConnectionOptions.DefaultTimeout.HasValue) | |||
| { | |||
| DefaultTimeout = ConnectionOptions.DefaultTimeout.Value; | |||
bricelam
Oct 24, 2020
Member
I think that if the user sets SqliteConnection.DefaultTimeout, it should take precedence. Only fallback to the connection string value when it’s unset.
I think that if the user sets SqliteConnection.DefaultTimeout, it should take precedence. Only fallback to the connection string value when it’s unset.
bricelam
Oct 24, 2020
Member
Also, do we ever use this value when the connection is closed? If so, we may need to read the value in the ConnectionString property setter.
Also, do we ever use this value when the connection is closed? If so, we may need to read the value in the ConnectionString property setter.
nmichels
Oct 24, 2020
Author
Contributor
Hi @bricelam
By unset you mean different from the default value (30)? Or should we implement a private property and explicitly check wheter the DefaultTimeout has changed in it's setter?
I'm not sure, but I think that it doesn't make sense to use this property value when the connection is closed.
Thanks!
Hi @bricelam
By unset you mean different from the default value (30)? Or should we implement a private property and explicitly check wheter the DefaultTimeout has changed in it's setter?
I'm not sure, but I think that it doesn't make sense to use this property value when the connection is closed.
Thanks!
nmichels
Oct 24, 2020
•
Author
Contributor
In fact, if we move this code snippet to the ConnectionString property setter we will have the desired precedence in most cases: connection string/default timeout set via constructor and then eventually programatically changed, if the user changes again the connection string it would affect again the Default Timeout, it kinda makes sense.
In fact, if we move this code snippet to the ConnectionString property setter we will have the desired precedence in most cases: connection string/default timeout set via constructor and then eventually programatically changed, if the user changes again the connection string it would affect again the Default Timeout, it kinda makes sense.
