|
From: Elias K. <ek...@na...> - 2002-12-24 23:53:54
|
Hello all and merry christmas!
I am in the process of extending the IBM DB2 driver and I have to put
forward some points that I came across while working with DBI:
1) Memory management in DBI should be rethought of. The DBI layer should
be lenient as to its usage by client apps, which means that calls like
Statement.finish or Database.disconnect should always do their thing
(free C buffers, close log files, turn off the coffee machine etc.)
regardless of their being called by the user script or not. For
instance, the following hypothetical script leaks like hell:
while [some boolean]
st = db.prepare([some sql])
st.execute([some values])
end
Yes, I know this is not the 'proper' way to use DBI (suppose I never
heard of 'Database.do'). But DBI should at least it should try to invoke
"st.finish unless st.finished?" in a finalizer closure if a statement
object is finalized without having freed its internal resources. The
same applies to database connections and other environment handles. I
don't know if the use of finalizers is the correct way to address the
problem, so I expect your thoughts on this.
2) Parameters returning values: Since some people (including myself)
will try to use Ruby-DBI with existing systems using stored procedures
at some point in time, there is very few support in DBI about returned
values from procedure calls. The problem is difficult to solve taking
into consideration that Ruby values created as results from stored proc
calls are not materialised until execution time, so bind_params is not
the place to do it. Actually, parameter binding should be two-phased
(before and after execution) so that parameters are bound to and from
the database, respectively.
What do you think?
Elias
|