[Laszlo-dev] For your review: Laszlo Database API spec version 1.1
max at laszlosystems.com
Fri Nov 4 16:56:52 PST 2005
>>> 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
>>> 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:
>> 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.
>> 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
More information about the Laszlo-dev