d-dbapi ALPHA-2 released

[Kirk McDonald]

Myron Alexander wrote:
> Kirk McDonald wrote:
[snip]
>> I would also try to find a way to ditch std.boxer. I never liked it. 
> 
> 
> I'm not a big fan of the Box solution either but it was the only one 
> that suited all the conditions. My primary condition is to mimic the 
> simplicity of the PEP249 array mechanism and specifying type up-front 
> causes a headache when working with NULL. I chose to represent NULL as 
> box(null) (mirroring the Python None mechanism) but you can't put a null 
> into an int.
> 

Oof. That does throw a wrench into the works.

> The other consideration, how to handle queries where the type is not 
> known upfront? One such case is the generic database viewer program. I'm 
> still learning D so I do not know all the template features. How would I 
> return a templated struct without supplying the types upfront?
> 

The tricky part is that, since D is a statically typed language, you 
must /always/ know the type of something when it comes time to use it. 
In other words, if you don't know the types involved, you can't extract 
the data and use it.

I've mused on this subject before, when I was thinking about how you'd 
write an ORM in D:

http://dsource.org/forums/viewtopic.php?t=2283

I remain convinced that something really brilliant would be possible on 
this front, but it would be a lot of work to get it right.

It turns out that my work on Pyd is highly relevant to this problem, 
since the problems are very similar: In both cases, you have some sort 
of collection of data of different types, and you can extract these 
types at runtime. Those runtime-types map fairly well onto D's native 
types. The trick is to basically turn the problem on its head: You 
define something in D, at compile time, and try to match the runtime 
data to it. If it doesn't match, it's an error.

In Pyd, you define a regular D function, and it tries to match function 
arguments from Python to the function's signature. With an ORM, you 
define a D class, and it tries to match values fetched from the database 
to the class's fields.

> I did come across a variant type yesterday 
> (http://www.prowiki.org/wiki4d/wiki.cgi?DanielKeep/Variant) that could 
> be better than the Box, especially if I specialize it for D-DBAPI but I 
> would need a use-case to see how much benefit over the Box solution it 
> would bring.
> 

That Variant is a nifty piece of work, but it has the same fundamental 
problem as boxer: You basically lose the type and then find it again. 
This generally makes me nervous and makes me want to fix something. 
(Hence my thinking about ORMs.)

> Kirk, thanks for taking the time to provide suggestions. Your comments 
> are valid and this is something I am struggling to solve. I'm a firm 
> believer that no matter how smart a person is, there is always someone 
> else that can see the problem in another light and can come up with a 
> better solution. At this time, I cannot see a better solution so all 
> suggestion are helpful.
> 

Your d-dbapi is smarter than DDBI when it comes to database rows. This 
was always DDBI's main problem, and it's good to see progress there.

-- 
Kirk McDonald
http://kirkmcdonald.blogspot.com
Pyd: Connecting D and Python
http://pyd.dsource.org