RE: Comments on Section 4.11.2 Databases and 4.11.3 Executing SQL statements

> -----Original Message-----
> From: public-html-request@w3.org 
> [mailto:public-html-request@w3.org] On Behalf Of Ben Meadowcroft
> Sent: 01 March 2008 10:24
> To: public-html@w3.org
> Subject: Comments on Section 4.11.2 Databases and 4.11.3 
> Executing SQL statements
> 
> I've got a couple of comments on section "4.11.2 Databases" 
> and "4.11.3 Executing SQL statements".
> 
> Comment on "4.11.2 Databases"
> This section states "The transaction() method takes one or 
> two arguments." yet the interface defined above this 
> statement shows that 3 arguments can be provided.
> 
> Comment on "4.11.3 Executing SQL statements"
> I would like to suggest adding support for named parameters 
> when executing SQL (in addition to the current array 
> mechanism). My proposal is that we allow named placeholders 
> in the SQL statement and then allow an object to be passed as 
> a parameter, replacing the placeholder with the value of the 
> matching named object property.
> 
> A specific example would be:
> transaction.executeSql(
>    "SELECT * from employee WHERE employee.firstname = 
> :firstname AND employee.salary < :salary;",
>    {"firstname" : "Ben", "salary" : 999.99},
>    callback
> );
> 
> I've used the Java Persistence API and Hibernate style of 
> named parameters, along with a more common JavaScript idiom 
> of using an object as an associative array.
> 
> I think the introduction of named parameters would help 
> reduce the programming errors that occur when dealing with 
> arrays and the implicit parameter ordering that this 
> requires. Another advantage is that applications could reuse 
> objects in use as query parameters rather than mapping them 
> to an array (in the right order!). For example:
> 
> transaction.executeSql(
>    "SELECT * from departent WHERE department.name = ? AND 
> department.location = ?;",
>    [employee.department, employee.location],
>    callback
> );
> 
> Would be:
> 
> transaction.executeSql(
>    "SELECT * from departent WHERE department.name = 
> :department AND department.location = :location;",
>    employee,
>    callback
> );
> 
> The mapping would be fairly simple and could be mapped onto 
> the existing array specification if required, e.g.: 1. take 
> the SQL string and extracting any named parameters into an 
> array, replacing them with the '?' placeholder 2. iterate 
> over the array, take then name of the parameter and look up 
> its property value on the object passed in, replace the 
> parameter name in the array with the retrieved value. 3. 
> continue processing with the modified SQL string (with ? 
> placeholders) and an array of parameters.
> 
> What are peoples thoughts on these suggestions?

A further suggestion is allowing a form node to be passed as a parameter to
the executeSql function and binding the named parameters to the values of
form controls with the same name that are associated with the passed in form
node.

-- 
Ben Meadowcroft
http://www.benmeadowcroft.com/

Received on Monday, 12 May 2008 22:12:52 UTC