byterock

Another in my seemingly endless posts for a new chapter in XS Fun. Today I am am going to look at just what and where my the functions from my last two posts store their data.

Now to do a little backtracking I hinted earlier on about a mythical 'c' struct called 'imp_dbh_t' and I had mentioned this is where we where storing the values that we where passing into the 'Store' function and getting from the 'Fetch' function.

No not to go all to 'c' on you what you really need to know it that a 'c struct' is just the way 'c' stores a number of variables in memory with one pointer. Working with structures should be second nature to a Perl programmer as you would access the data in a struct with it name or key like this

 
imp_dbh->ha_function

If you think it looks very similar any of these Perl lines

 

my  $value = $my_hash{some_key};

my  $value = $my_hashref->{some_key};

my $result  = $my_object->some_method;

Then you are not too far away from the concept of the struct and if you are really keen you can pop into Perl Guts and read about the internal code if you dare.

The point is the struck like a Perl hash is an easy way to get at your data in a structured way without having to declare a whole bunch of local variables. Now unlike Perl structs are static and have to be declared (or at least should be) before compile time. As many 'c' programmers like modularized code they are usually put in to a '.h' or header file so they can be reused by other '.c' programers, Now in our case it is the 'dbdimp.h' that I am going to patch next

Now I what I need to do is creating the memory space for the data coming from Perl, the ha function name or code ref, as well as space in my '.c' program for the what is coming back from Oracle on the callback so lets add that in first like this

 
++//*--------------------------FAN Callback Structure ---------------------*/

++typedef struct ha_ctx_st ha_callback_t;

++struct ha_ctx_st {

++  SV   *function; /*User supplied FAN function*/

++  SV   *dbh_ref;

++};

/*--------------------------TAF Callback Structure ---------------------*/

This is 'c' of course so I have to define my structure first before I can declare it and next I add in the two data types I need again both XS SVs (perl scalars) the first being the pointer to my HA function, either a name or a code ref and the next is a pointer to the current DBI db handle, or in simple terms the object that I am calling the call back from. Now this is the 'c' structure that we are going to pass off to Oracle as 'Context' of our callback more on this much later.

Next I will add in the following to the 'imp_dbh_st' strut a little further down in the '.h' file

 
        ub4	     driver_namel;
++    SV         *ha_function; /*HA function */
++   	ha_callback_t ha_ctx;
#endif

Again I am adding these values within that ' ORA_OCI_112' compiler directive yet again one has to be very consistent with 'c'.

Now the SV ha_function is where that the value from the STORE and FETCH functions above is stored and the ha_callback_t ha_ctx is a reserved spot where we are going to store the current context for future use.

So that is about it for data structures lets move back into the 'dbdimpl.c' file again for the next patch.

Well that is is for tonight by the way watch for tomorrow post where I really start to hit the XS code.