[GSOC] Database API draft proposal

[Piotr Szturmaj]

Fawzi Mohamed wrote:
> 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.

I'm ready to cooperate :)

>>> * 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.

I've just added row["column"] bracket syntax for dynamic rows.

>
>>> * 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.
>

Could you elaborate? I don't know what do you mean.

>>> * 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.

A "defined" DBRow or static one, if used on result which has inequal 
number of columns or their types aren't convertible to row fields then 
it's an error. But, if someone uses a static fields, he should also take 
care that the query result is consistent with those fields.

>>> * 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)
>

I should state here, that end-user usability is very important to me. I 
should also clarify that my code isn't completely finished and of course 
it is a subject to change. Any suggestions and critics are welcome :)