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

[Henry Minsky]

I used to work on a system called OpenACS
(www.openacs.org<http://www.openacs.org>)
which is a app server environment that uses Tcl and AOLserver.

There were many modules that people wrote, and the system can be targeted to
Oracle, Postgres, and maybe some other database I am not sure.

It is very instructive to see how they did the back end for various modules,
such that they could target Oracle or Postgres.

A module, such as a calendar or mailinglist manager, would have a directory
of
files, with oracle or postgres-specific queries broken out into separate
files, while queries which could be common between them would be in a
generic sql file. Each query was given a name, so that the common code would
refer to it by name, and the code for the individual databases would be
given the best possible implementation.



On 11/3/05, Max Carlson <max at laszlosystems.com> wrote:
>
> Hi Henry,
>
> Thanks for your feedback. I'll definitely put some more background on
> how the spec will ultimately work in the context of Laszlo. Replies below:
>
> Henry Minsky wrote:
> > I'm a little unclear on how things are divided up to build an app. When
> > you declare a model, that gets compiled on the *server* into a a
> > database schema and a handler that accepts incoming URLs which contain
> > those path-like commands, right?
>
> Correct.
>
> > On the client, there is some protocol that can deserialize the results
> > of commands and turn them into .. .what? datasets?
>
> A dataset. As the records in the dataset are mutated, change commands
> would accumulate on the client. They would then be sent up to the
> server to alter the data source.
>
> > One thing I am concerned about is what is the mechanism where the user
> > can override or extend the SQL that is automatically compiled, and
> > directly right their own "command handlers" (I'm not sure what to call
> > this) on the server?
>
> I'll add a post-processing callback that allows developers to alter the
> generated SQL as they see fit.
>
> I'll also add a more generic kind of method call that specifies a method
> signature that gets invoked on the server.
>
> > In my experience, each particular brand of database you choose for the
> > back end will have many of its own quirks or unique non standard
> > features, which you will often want to take advantage of, so it would be
> > important to be able to manually write your own "methods", and
> > particulary in the case where you do complex transactions than involve
> > touching a lot of tables, or that involve calling stored procedures in
> > some complex way...
>
> The idea is to hide or abstract as much of that complexity as possible,
> but I agree, we need the escape hatch.
>
> Thanks again!
>
> -Max
>



--
Henry Minsky
Software Architect
hminsky at laszlosystems.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openlaszlo.org/pipermail/laszlo-dev/attachments/20051103/07c6cf9e/attachment.html