[Laszlo-dev] For your review: Laszlo Database API spec version 1.1

[Max Carlson]

Hi Geert,

>>> Hi Max,
>>> I'm still wondering why you put SQL inside the model. If you only   
>>> declare abstract methods with arguments, what use it is to have  SQL  
>>> attached to it?
>>
>>
>> There are now two types of methods - native and SQL.  The SQL in  SQL 
>> methods is literally used for the WHERE clause for SQL methods  
>> statements to provide record-level access.  The client doesn't have  
>> any way to access this SQL - it can only send arguments for  methods, 
>> regardless of if those methods are type native or SQL.
> 
> 
> Yes, but what why do you need to make the distinction, and why do you  
> need to push SQL into the server-side generated model data? Are the  
> declaration of abstract methods with a signature not sufficient?

The goal of this is to make it easy for developers to access 
record-based datasets, SQL in particular.  To that end, we try to 
autogenerate as much of the SQL as possible for them.  One place that 
becomes difficult to do declaratively is in WHERE clauses.  The other 
place is in ORDER BY clauses.

I added native methods to satisfy the requirement of being able to do 
other things.  Given the requirements, I'm still not sure how SQL 
methods and order statements could (or should) be replaced by procedural 
code.

>>> I also have another remark, I think you should formalize the  types  
>>> that are supported for the fields and standardize again on  a 
>>> standard  set for this and reduce the DB-specific types (like  text 
>>> for  example). Some material:
>>> http://java.sun.com/j2se/1.5.0/docs/guide/jdbc/getstart/mapping.html
>>> http://www.faqs.org/docs/ppbook/x2632.htm
>>
>>
>> Good point. We'll need to do this for the client-side  implementation. 
>> In the end, types will need to be coerced by the  client, depending on 
>> what types are supported by the runtime.
>>
>> If we can assume the client is always JavaScript/ECMAscript, doing  it 
>> on all on the server makes sense.  If we want to support other  client 
>> languages (I think we do), then this will have issues, e.g.  ECMA only 
>> has number, but Java has float and int.  It does make  sense to 
>> standardize on the server though, to cut client-side  mapping work 
>> down.  I'll think about this...
>>
>>> I also have trouble of seeing why Callbacks should be specified  in  
>>> the spec. Isn't that totally server-side?
>>
>>
>> Yes - it is totally server side.  The spec is all server-side.  The  
>> client-side portion still needs to be written up and built...
> 
> 
> So ... what is the purpose in this spec?

To make it easy for developers to interact with record-based datasets on 
the server without requiring them to write much (or any) code on the 
client or server to do so.

The client-side work is well thought out, but since it isn't being 
developed by the same people doing the server-side implementation it 
isn't in this spec.  In a nutshell, it's an implementation of dataset 
that knows how to speak the HTTP protocol and rollback changes that 
didn't go through.  This should be part of the spec, but I've had very 
limited time to work on this.

Providing an open, HTTP-based protocol for working with record-based 
data that doesn't require Laszlo or a specific back-end technology is a 
nice side-effect.

Regards,
Max Carlson
OpenLaszlo