I'm going to leave this here as an open issue, in the unlikely event that someone else out there has a strong opinion on the subject.
As of now the identity column for the QueryLogs table has a data type of int (and, naturally, the corresponding Query C# entity also has a type of int). While the number of queries we log per day is not totally insignificant (100k+) this is more than sufficient for our needs and it just seems like overkill to use anything else.
However, I can certainly imagine other scenarios out there where people might be logging things with a higher throughput and they would prefer a bigint SQL Server data type (and a corresponding type of long on the C# object). So... in the unlikely event that anyone ever hits this issue feel free to let me know here. It's the kind of thing that could be changed in v2.0 release.
(This question probably applies equally to the ExecutionTime field, especially if a client has long-running queries that they want to log, and particularly if they want to run calculations on that data.)
I'm going to leave this here as an open issue, in the unlikely event that someone else out there has a strong opinion on the subject.
As of now the identity column for the
QueryLogstable has a data type ofint(and, naturally, the correspondingQueryC# entity also has a type ofint). While the number of queries we log per day is not totally insignificant (100k+) this is more than sufficient for our needs and it just seems like overkill to use anything else.However, I can certainly imagine other scenarios out there where people might be logging things with a higher throughput and they would prefer a
bigintSQL Server data type (and a corresponding type oflongon the C# object). So... in the unlikely event that anyone ever hits this issue feel free to let me know here. It's the kind of thing that could be changed in v2.0 release.(This question probably applies equally to the
ExecutionTimefield, especially if a client has long-running queries that they want to log, and particularly if they want to run calculations on that data.)