[GSOC] Database API draft proposal

[Fawzi Mohamed]

On 3-apr-11, at 22:54, Daniel Gibson wrote:

> Am 03.04.2011 20:15, schrieb Fawzi Mohamed:
>> On 3-apr-11, at 19:28, Piotr Szturmaj wrote:
>>
>>>> * 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)
>>
>
> I'd hate not having a rows-and-tables view onto the database.
> An Object-Relational-Mapper is nice to have of course, but I agree  
> with Piotr
> that a traditional view onto the DB is a good start to built an ORM  
> on and I
> think that the traditional view should also be available to the user  
> (it'll be
> there internally anyway, at least for traditional relational  
> databases).

I fully agree, I probably did not express me clearly enough, a basic  
table view is a must, but the ORM that one wants to realize might  
influence how exactly the basic view looks like.
For example it would be nice if a basic row would also somehow be the  
basic object of the ORM with a dynamic description, and automatically  
specialized if the db description is available at compiletime.
As I had said before "the object level can influence the choice of the  
best low level interface", this does not imply that a lower level  
interface is not needed :).

> Also: How are you gonna write queries with only the ORM view? Parse  
> your own
> SQL-like-syntax that uses the Object type? Or have the SQL operators  
> as methods?
> And then generate the apropriate SQL string?
> What about differences in SQL-syntax between different databases?
> What about tweaks that may be possible when you write the SQL  
> yourself and not
> have it generated from your ORM?
>
> No, being able to write the SQL-queries yourself and having a "low  
> level" view
> (tables and rows, like it's saved in the DB) is quite important.

again I fully agree, but if we want to be able to store business logic  
in objects that come from the database, and be able to express them  
easily (for example like ruby does), can be very useful.
At the ORM level one should express at most simple queries, for more  
complex stuff SQL is a must (there is no point to define another DSL  
when SQL is already one (but having special methods with common  
queries can be useful to more easily support non SQL dbs).

> However: Since Piotr already seems to have much work done, maybe  
> Christian
> Manning could polish Piotrs work (if necessary) and create a ORM on  
> top of it?

if accepted I definitely think that Piotrs and Christian will have to  
coordinate their work

> Oh, and just an Idea: Maybe something like LINQ is feasible for ORM?  
> So you can
> write a query that includes local containers/ranges, remote  
> Databases (=> part
> of it will internally be translated to SQL) and maybe even XML (but  
> that could
> be added later once the std.xml replacement is ready)?

well simple queries, not sure if a full LINQ implementation is too  
much to ask, but simple queries should be feasible.

Fawzi