Re: First DBDI draft

Tim Bunce wrote:
> On Thu, Jan 29, 2004 at 09:00:56PM +0000, Harry Jackson wrote:
> 
>>.pcc_sub _MAIN prototyped
>>    .param pmc argv
>>    .include "/home/parrot/dbdi/lib/dbdi/dbdi_header.imc"
>>    
>>    .sym string dbstring
>>    .sym PerlHash dbh 
> 
> 
> The application shouldn't need to know the type of the thing returned.
> Can you use a 'reference' type here instead of PerlHash?

This is relatively easy to fix. I am pretty sure we can just change the 
line above to ".sym pmc dbh" with no ill affects we just need to 
remember how we access it.

>>    dbstring = "host=lhost dbname=name user=user password=pass"
>>    .pcc_begin prototyped
>>        .arg dbstring 
>>            .pcc_call connect 
>>            retconnect:
>>        .result dbh
>>    .pcc_end
>>    print "New $dbh successful????\n"   
> 
> 
> When we move to objects we'll add in the driver handle and call connect
> as a method on that.

The actual connect call above is the DBDI call which then calls the 
connect function on the driver.

> I'd like to see username and password moved to separate parameters
> and an attributes parameter added. (To get as close to the final
> API as early as possible).

I can split the parameters up and we have the ability to concat strings 
  so this should be straight forward.

I would like to put each arg in an array and pass that in rather than 
having a massive arg list or would you rather have them all seperate.


>>    # Now that we have a $dbh we can pass it into
>>    # the prepare funtion with the SQL statement
>>    .sym Sub sth
> 
> Er, Sub for sth?

Don't ask. If you seen the comments in the function call it was actually 
being ignored. The dbh holds everything I need to connect to the 
database so I made it global and was using it. This has actually changed 
now. I have it as a PerlHash but will change it to ".sym pmc"

> Is that returning a new PerlArray each time?
> I think that should be another reference and have fetch() return
> a reference to the same (internal) PerlArray each time.

It is buried in the driver somewhere so I will need to dig to find out. 
If it is it should be easy to fix. Would you prefer to have the array 
passed in as a parameter. This means we can create it before the loop 
and reuse it.

> rowcount shouldn't be returned (could be a global for now).
> Use a nil/null reference in rowarray to indicate no more data.

Roger.

>>I want to return some object like structures back
>>from the functions above rather than hiding
>>everything in the background. This will make it
>>easier to see and know what is going on between calls.
> 
> 
> I'm not sure what that means.

The original DBDI test suite I came up with did not take or return any 
parameters except the dbstring at the start. You just made the funtion 
calls and everything was handled at the back end. I need to update this 
documentation to reflect each DBDI example suite that gets releases.


Harry