rufus-tokyo : tctdbqryproc, Matthew King's patch
John Mettraux
I've integrated your patch, thanks a lot !
http://github.com/jmettraux/rufus-tokyo/commit/5c9897c94de2d9da9736026de17dc71637be599f
I was wondering though : wouldn't it be a bit better to encourage
users to put the process block outside of the query itself, more like
:
Since process actually does something on the query, I think the
workflow "prepare then process" is less confusing than "mixing process
in prepare".
Also, rereading about tctdqryproc :
---8<---
bool tctdbqryproc(TDBQRY *qry, TDBQRYPROC proc, void *op);
`qry' specifies the query object of the database connected as a writer.
`proc' specifies the pointer to the iterator function called for
each record. It receives four parameters. The first parameter is the
pointer to the region of the primary key. The second parameter is the
size of the region of the primary key. The third parameter is a map
object containing columns. The fourth parameter is the pointer to the
optional opaque object. It returns flags of the post treatment by
bitwise-or: `TDBQPPUT' to modify the record, `TDBQPOUT' to remove the
record, `TDBQPSTOP' to stop the iteration.
`op' specifies an arbitrary pointer to be given as a parameter of
the iterator function. If it is not needed, `NULL' can be specified.
If successful, the return value is true, else, it is false.
--->8---
We should really leverage TDBQ{PUT|OUT|STOP}, that'd really make this
process method fit its name.
Wdyt ?
--
John Mettraux - http://jmettraux.wordpress.com
Matthew King
>
> Hi List, Hi Matthew,
>
> I've integrated your patch, thanks a lot !
>
> http://github.com/jmettraux/rufus-tokyo/commit/5c9897c94de2d9da9736026de17dc71637be599f
>
> I was wondering though : wouldn't it be a bit better to encourage
> users to put the process block outside of the query itself, more like
> :
>
> http://gist.github.com/131006
>
> Since process actually does something on the query, I think the
> workflow "prepare then process" is less confusing than "mixing process
> in prepare".
I haven't tested, but won't the current code work as you say?
tctdbqryproc just augments a query; whether done in your query block
syntax, or done in a prepared query, I believe it should work.
>
> Also, rereading about tctdqryproc :
>
> ---8<---
> bool tctdbqryproc(TDBQRY *qry, TDBQRYPROC proc, void *op);
> `qry' specifies the query object of the database connected as a writer.
> `proc' specifies the pointer to the iterator function called for
> each record. It receives four parameters. The first parameter is the
> pointer to the region of the primary key. The second parameter is the
> size of the region of the primary key. The third parameter is a map
> object containing columns. The fourth parameter is the pointer to the
> optional opaque object. It returns flags of the post treatment by
> bitwise-or: `TDBQPPUT' to modify the record, `TDBQPOUT' to remove the
> record, `TDBQPSTOP' to stop the iteration.
> `op' specifies an arbitrary pointer to be given as a parameter of
> the iterator function. If it is not needed, `NULL' can be specified.
> If successful, the return value is true, else, it is false.
> --->8---
>
> We should really leverage TDBQ{PUT|OUT|STOP}, that'd really make this
> process method fit its name.
I spent some thought on that, but couldn't find a fit for Ruby block
semantics. Using Ambition to hook in Ruby-as-query-language might
allow you to take advantage of return flags. I'm thinking #delete_if,
here, driven by TDBQPOUT.
TDBQPSTOP would be the equivalent of calling break in a block. I
don't recall any way in Ruby to determine if a block exited on a
break.
Regarding TDBQPPUT, I must confess I did not understand how that
works. What modifies the record, and how?
John Mettraux
>
> On Tue, Jun 16, 2009 at 7:41 PM, John Mettraux<jmet...@openwfe.org> wrote:
>>
>> Hi List, Hi Matthew,
>>
>> I've integrated your patch, thanks a lot !
>>
>> http://github.com/jmettraux/rufus-tokyo/commit/5c9897c94de2d9da9736026de17dc71637be599f
>>
>> I was wondering though : wouldn't it be a bit better to encourage
>> users to put the process block outside of the query itself, more like
>> :
>>
>> http://gist.github.com/131006
>>
>> Since process actually does something on the query, I think the
>> workflow "prepare then process" is less confusing than "mixing process
>> in prepare".
>
> I haven't tested, but won't the current code work as you say?
> tctdbqryproc just augments a query; whether done in your query block
> syntax, or done in a prepared query, I believe it should work.
Hi Matthew,
yes it will work OK out of the query preparation block.
>> We should really leverage TDBQ{PUT|OUT|STOP}, that'd really make this
>> process method fit its name.
>
> I spent some thought on that, but couldn't find a fit for Ruby block
> semantics. Using Ambition to hook in Ruby-as-query-language might
> allow you to take advantage of return flags. I'm thinking #delete_if,
> here, driven by TDBQPOUT.
>
> TDBQPSTOP would be the equivalent of calling break in a block. I
> don't recall any way in Ruby to determine if a block exited on a
> break.
>
> Regarding TDBQPPUT, I must confess I did not understand how that
> works. What modifies the record, and how?
I've got an idea on how to do that. Give me some time.
Best regards,
John Mettraux
>
>>> We should really leverage TDBQ{PUT|OUT|STOP}, that'd really make this
>>> process method fit its name.
>>
>> I spent some thought on that, but couldn't find a fit for Ruby block
>> semantics. Using Ambition to hook in Ruby-as-query-language might
>> allow you to take advantage of return flags. I'm thinking #delete_if,
>> here, driven by TDBQPOUT.
>>
>> TDBQPSTOP would be the equivalent of calling break in a block. I
>> don't recall any way in Ruby to determine if a block exited on a
>> break.
>>
>> Regarding TDBQPPUT, I must confess I did not understand how that
>> works. What modifies the record, and how?
>
> I've got an idea on how to do that. Give me some time.
Hello,
I've came up with :
In the specs it looks like :
I've made sure to add it to Rufus::Edo as well.
It should still match your way of using it.
Many thanks,