On 3/15/20 6:31 AM, Nick Kew wrote:
...
Is there guidance or a standard for driver writers
elsewhere?
No. Apart from our own needs, we just have occasional feedback
from users like yourself.
Just thinking aloud here, I wonder if an apr_dbd_row_alloc API
would meet your needs? I haven't thought through how it
would be implemented, and it also raises the question of whether
allocator APIs for other apr_dbd structs might be in order.
I am very interested in this outcome as I have run into a similar
(perhaps it is the same) issue. I have chosen to live with my work
around until my code is more complete. I have a unit test called
test_storage_successive_read where I debugged this issue but did not dig
into it much, as I was not prepared to try and determine if there was a
bug and where it might lie at that time.
Here are the comments from my code:
// the above statement has no results. if we use the Statement var
again
// we will get no results when calling apr_dbd_get_row()
...
//there seems to be a bug when creating the statement and using it
//right away
//if we set it to NULL before hand, however, it is fine.
//if we do not set Statement = NULL; all subsequent statements will
have no
//results.
I then simply:
Statement = NULL;
before using the variable again.
I am calling apr_dbd_pselect with various statements one after the other
in order to find why in my program loop there was only the first result.
Setting the apr_dbd_prepared_t * to NULL seemed to fix the issue. It
seemed quite odd to me. When I saw Steven's email, I remembered about my
own similar issue. So I thought I should comment and offer to provide
some test code and help debug the issue.
I am using libaprutil1:amd64 1.5.4-3 on Debian if that makes a difference.
Best regards,
Simon
