Monday, June 4th, 2007

Google Gears DB Abstractions

Category: Gears, Google, JavaScript, Library

I had a feeling that this would happen pretty quickly. The Google Gears APIs are fairly low level, which leaves room for higher level abstractions.

I ported an old abstraction over with gears-dblib, which allows me to not repeat myself in a number of areas.

I personally prefer working with objects than result sets for example, which leads to:


  1. db.selectAll('select * from person where name like ?', ['bob%'], function(person) {
  2.     document.getElementById('selectAll').innerHTML += ' ' +;
  3. });
  5. // or
  7. db.selectRows('person', 'name like ?', ['%'], function(person) {
  8.    document.getElementById('selectRows').innerHTML += ' ' +;
  9. });
  11. // or
  13. var harry = db.selectRow('person', 'id = 1');

I also find myself often writing logic such as “insert this into the db unless it is there”, which has been wrapped into insertRow (for times when you don’t/can’t use a db constraint):


  1. db.insertRow('person', bob);
  2. db.insertRow('person', bob, 'name = ?', ['Bob']); // unless a Bob is there

You can see a bunch of this running in debug mode (Firebug / Lite) here.

Uriel Katz wrote a simple ORM for Gears that lets you do things like:


  1. var MyModel = new GearsOrm.Model("MyModelName",{
  2.   myModelField:GearsOrm.Fields.String({maxLength:25})
  3. });
  5."myModelField = ?",["MyValue"])

I am sure that someone is porting ActiveRecord, and Hibernate, as we speak.

Posted by Dion Almaer at 1:29 am

3.6 rating from 24 votes


Comments feed TrackBack URI

thanks for posting about my work :).
i read your code,and i most say i am really impressed.
now that i see there is interest,i am doing a rewrite to support relations,cascading and etc.

Comment by uriel katz — June 4, 2007

This is genuinely impressive stuff guys…
But will someone please explain, why?
I really want to be convinced that offline apps are big and cool and important, but will I ever need to use one?

Comment by stu — June 4, 2007

think of a world that doesn`t have the bad “next,next,next”,no package managers,you just type a url and start working,no more bullshit,no more version update,just stuff that work.
that is the promise of Web applications that work also offline.

now these abstractions are just to make the developer life eaiser :)

Comment by uriel katz — June 4, 2007

Hmm. Maybe if we pose the question the other way around; Given the extreme ease and power of javascript, why would we ever again want to write any server-side code whatsoever, if valid alternatives exists here were the action is.

I hope that the future brings us static and minimalistic server-side “middleware” which only implement what absolutely cannot be implemented on the client (security, proxying and storage aggregation, for instance), leaving us with only the good times in life :)

psvensson at gmail dot com

Comment by Peter Svensson — June 4, 2007

as much is i like JavaScript,i would prefer Python more than JavaScript ;)
as of using the Server-Side as a proxy,that is how most Web Applications work,the server side is a proxy to the database and to a businesses logic.

Comment by uriel katz — June 4, 2007

I don’t really know if this is the right way to go, I know that this is the future, but we worked a lot on kickass opeating system features and we force ourself using clunky html – javascript – css while there is so much better on the desktop side of our computers.

Comment by web design firenze — June 4, 2007

Hi, it’s cool.

GearsSQL, is a good port from php ezSQL class. The documentation is in Spanish but it’s so good.

Comment by Dan — June 4, 2007


Could you explain about db login data? Where this sould be stored?


Comment by Nick — June 4, 2007

Am I the only one worried about security? What would stop an evil guy from doing SELECT * FROM users or even worse DELETE FROM xxxx? Most of the server side frameworks, even PHP frameworks, have tried so hard to give us programmers nice tools to circumvent these kinds of problems. Problems which arise from an untrustworthy client sending some manipulated query. And now SQL shall be done client side? What a piece of unpracticable crap.

Comment by Jojo — June 4, 2007

I’m more concerned about solving multi-user issues when it comes to offline database content. If it’s only one user manipulating the data in the database, fine. If there’s lots of people accessing the same data and manipulating it, they’re going to have a great time reviewing all changes that collide.

For me, the point of a web application is that multiple people see the same data wherever they are, knowing that the data is up to date.
And I must agree with Jojo – javascript db queries? Either it’s not secure at all, or the programmers have to be really sure that the users can’t send the wrong queries to the server.

Comment by Anders Mattson — June 4, 2007

I took a quick peak at the source and it looks like the SQL only goes as far as the Google Gears Database Module, instead of anything server-side.

That said, this bit of the description cracks me up, considering the scripts all exist in cleartext in the control of the user’s browser:

SQL statements passed to execute() can and should use bind parameters (?) to prevent SQL injection attacks.

Comment by Shawn Lauriat — June 4, 2007

Or….you could just do it all online. Am I the only one who’s not seeing the purpose?

Comment by stu — June 4, 2007

about code security,you always can manipulate a ajax application to do bad things,there should be also a server-side validation like in everything else.

Comment by uriel katz — June 4, 2007

Since the database is stored into the user computer,if he deletes the data or do anything else with it , he will be deleting his data only, not having any effect in any other users. So the “bad” user will be really be ruining himself…

Comment by Rodrigo — June 4, 2007

This is just “Make Available Offline” for ‘web apps’. You used to be able to just save all the HTML & links from a site and navigate the site offline. Now, most web pages serve content to you that is independent of what other users see on the very same URL. You, the user, can’t keep any of that, not even a cache. So if you pull the cable, you’re hooped. What if you are typing an email in Webmail, your dsl/wireless/dialu-up flakes out 1 second before hitting “Save Draft” ? Your totally screwed even after restarting your connection.

Some will want gears, some won’t. It should make a lot of sense for many very large, custom content sites. Obviously, not all sites should even consider it right away.

Comment by easyleft — October 4, 2007

Leave a comment

You must be logged in to post a comment.