[Building Sakai] Sakai BasicSQLService - Can we add dbUpdate() Methods?

csev csev at umich.edu
Tue Jul 19 18:11:29 PDT 2011


On Jul 19, 2011, at 1:06 PM, csev wrote:

> Sakai's BasicSQL Service is missing the ability to handle UPDATE statements. 

More detail:

I need dbUpdate() to support a more RESTFUL (i.e. edit-free) pattern.

If you put data like ID and send it out to a browser and then get it back, you need to verify the ID before you just do an UPDATE.

Imagine table with 

ID Integer AutoIncrement
SITE_ID  String
DATA String

Lets say you put up a list of these things in a UI with edit buttons with an ID=parameter - then on the edit screen you make ID a hidden parameter DATA, make changes to DATA and then you hit Save

If you know if a user is access, maintain, or admin, you can do the following.

For admin they can update any item:

UPDATE table SET DATA='stuff' WHERE ID=5

For maintain they can update any item in the current site (in which they have admin):

UPDATE table SET DATA='stuff' WHERE ID=5 and SITE_ID='123456 (current context)"

I could do a SELECT and then check SITE_ID, and then do the UPDATE if the SITE_ID matches.  But ...

That should be done in a transaction to insure things don't change between the SELECT and UPDATE.  

If I get dbUpdate() and get a sense of the number of rows affected, then I can effectively combine the SELECT and UPDATE into a single command with no need for a transaction.

If I get zero rows updated, it means that the UPDATE failed because ID was bad, or SItE_ID was a mis-match or did not exist.  If I get one row updated - that is goodness.  If I get two or more rows updated, it probably means I need a uniqueness constraint on (ID, SITE_ID).

It is a way to turn the UPDATE into a free and implicit UPDATE.

/Chuck



More information about the sakai-dev mailing list