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

[Geert Bevin]

Hi Max,

>> Can you give a use-case and an example for this? I still have  
>> trouble  seeing why you need the WHERE and ORDER BY clauses in the  
>> model.
>
> I suppose you don't strictly need them listed, but it's more  
> complex to generate them from code.  This is partially for ease of  
> implementation, and partially for ease of use.

Ease of use for who? For the developer that creates the client-side?  
I think this actually makes it more confusing.

> One use case is where you want the records returned to be  
> restricted to a specific user id.  Say the user id needs to come  
> from the session. ${} substitution takes care of filling this in,  
> though it's easy for a native method to do this also.  Next, we  
> need to filter the resulting record set to only records whose  
> userid matches.  This is best done as part of a SELECT statement.   
> We could do the filtering later as part of a native method, but  
> that is resource intensive and doesn't leverage the database's  
> strengths.  Ordering is another one of those cases.  The native  
> method could write the ordering/where parts of the SQL, but if  
> you're going to do that, why not use a native method for the entire  
> thing?
>
> I guess what it comes down to is all the other SQL is fairly  
> straightforward to autogenerate.  The WHERE and ORDER BY SQL isn't  
> and it needs to come from somewhere, so why force developers to  
> generate it in native code?
>
> After all, developers can use a native method to do whatever they  
> want!

Max, I still don't understand why you need SQL methods. When writing  
a spec, I think you should always simplify as much as possible. I'm  
not talking about doing filtering in the native language of course,  
I'm talking about the published methods being methods of a DAO that  
interact with any persistence strategy possible.

I feel like we're talking in circles here. Maybe I'm not getting  
something. Would it be possible for you to create a simple sequence  
diagram that illustrates the calling of a SQL method together with  
the data that's being exchanged between the client and the server?  
This would eventually be beneficial for your document too.

>> So the implementation of the callbacks will actually be done by   
>> developers on the server-side, inside the XML declaration of the  
>> model?
>
> Callbacks will be implemented in the native language of the server,  
> like native methods.  Both will come from code included by the  
> server at runtime.  I think it gets messy if it's in the XML.  For  
> Java it poses all kinds of issues, like needing to invoke the  
> compiler...  I'd prefer it be precompiled for a language like Java,  
> and included as source for more dynamic languages like Ruby and  
> PHP.  What do you think?

This confirms my initial feeling: I don't see what they are doing  
inside the spec, this is totally related to persistence strategy of  
the server-side implementation and there's no need to let them bleed  
through.

I noticed one more thing, commit and rollback. How do you think these  
will work? Do you intend them to work after a series of DML SQL  
statements that are executed through URL method calls?

Best regards,

Geert

--
Geert Bevin                       Uwyn bvba
"Use what you need"               Avenue de Scailmont 34
http://www.uwyn.com               7170 Manage, Belgium
gbevin[remove] at uwyn dot com    Tel +32 64 84 80 03

PGP Fingerprint : 4E21 6399 CD9E A384 6619  719A C8F4 D40D 309F D6A9
Public PGP key  : available at servers pgp.mit.edu, wwwkeys.pgp.net