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
