On Monday, 30 September 2013 at 10:34:25 UTC, Kagamin wrote:
On Sunday, 29 September 2013 at 15:42:10 UTC, simendsjo wrote:
the previous, but is this the best way? If we choose to
disallow new commands, that means the user have to explicitly
close a lazy command.
If a command isn't closed as soon as possible, it sounds like a
resource leak. If you silently cancel previous query, it can
hide logical bug.
Yeah. We need to choose:
1) Starting a new command while another is in flight is an error
You need to close explicitly if the command isn't finished
2) If another command has been started, it's er error to continue
iteration of a previous command.
I'm in favor of 1).
If using classes, we can safely have several instances for a
command (is this neccessary?)
If you execute the same query repeatedly, there's no need to
build the same command every time.
That's what prepared statements are for. If you don't even have
parameters, it's just 9 bytes (4 of these bytes is an
undocumented field called iteration_count..).
The problem is that MySQL is inconsistent here, and it depends
on if it's a field or a constant. SELECT TRUE is not the same
as SELECT boolean_field.
Also, it seems every constant integer is returned as LONGLONG.
But.. The fields include a length property..
Is there some hint it's true and not something else?
Yeah. BOOL is an alias for TINYINT(1). I think it's fair to
always assume TINYINT(1) is bool. For other types I'm not quite
sure though.. "SELECT 1" is a LONGLONG, but in D a literal is int
unless specified otherwise. So there is a mismatch here.
