[GSOC] Database API draft proposal

[Fawzi Mohamed]

On 3-apr-11, at 19:28, Piotr Szturmaj wrote:

> Fawzi Mohamed wrote:
>> Looking more maybe I was a bit too harsh, if you define clearly the
>> goals of your API then yes it might be a good project.
>> The api doesn't have to be defined yet, but a more detailed  
>> definition
>> of its goals should be there, maybe with code example of some usages.
>> Questions that should be answered:
>
> I know your response is'nt to me, but please let me answer these  
> questions from my point of view, based on my recent work on ddb.

I think that your responses are very relevant, as it seems to me that  
your work is nice, and I find that if a GSoC is done in that direction  
it should definitely work together with the good work that is already  
done, let's don't create multiple competing projects if people are  
willing to work together.

>> * support for static and dynamic types.
>> how access of dynamic and static types differs, should be as little  
>> as
>> possible, and definitely the access one uses for dynamic types should
>> work without changes on static types
>
> If you mean statically or dynamically typed data row then I can say  
> my DBRow support both.

yes but as I said I find the support for dynamic data rows weak.

>> * class or struct for row object
>
> I'm using struct, because I think row received from database is a  
> value type rather than reference. If one selects rows from one table  
> then yes, it is possible to do some referencing based on primary  
> key, but anyway I think updates should be done explicitly, because  
> row could be deleted in the meantime. In more complex queries, not  
> all of selected rows are materialized, i.e. they may be from  
> computed columns, view columns, aggregate functions and so on.  
> Allocation overhead is also lower for structs.
>
>> * support for table specific classes?
>
> Table specific classes may be written by user and somehow wrap  
> underlying row type.

well with the current approach it is ugly because your calls would be  
another type, thus either you remove all typing or you can't have  
generic functions, accepting rows, everything has to be a template,  
looping on a table or a row you always need a template.

>> * reference to description of the table (to be able to get also  
>> dynamic
>> types by column name, but avoid using too much memory for the  
>> structure)
>
> My PostgreSQL client already supports that. Class PGCommand has  
> member "fields", which contain information about returned columns.  
> You can even check what columns will be returned from a query,  
> before actually executing it.

ok that is nice, and my point is that the type that the user sees by  
default should automatically take advantage of that

>> * Nice to define table structure, and what happens if the db has  
>> another
>> structure.
>
> This is a problem for ORM, but at first, we need standard query API.

I am not so sure about this, yes these (also classes for tables) are  
part of the ORM, but the normal users will more often be at the ORM  
level I think, and how exactly we want the things look like that the  
object level can influence the choice of the best low level interface.

>> * you want to support only access or also db creation and  
>> modification?
>
> First, I'm preparing base "traditional" API. Then I want to write  
> simple object-relational mapping. I've already written some code  
> that generated CREATE TABLE for structs at compile time. Static  
> typing of row fields is very helpful here.

Very good I think that working on getting the API right there and  
having it nice to use is important.
Maybe you are right and the current DBRow is indeed the best  
abstraction, but I am not yet 100% sure, to me it looks like it isn't  
the best end user abstraction (but it might be an excellent low level  
object)