Wednesday, January 14th, 2009

ActiveRecord.js Released: ORM for Multiple JavaScript Environments

Category: Announcements, Aptana, Gears, Storage

<p>Aptana has put out their first beta release of ActiveRecord.js. The details according to Ryan Johnson, a developer at Aptana:

ActiveRecord.js is an open source object relational mapper (ORM) that supports multiple JavaScript environments, including:

  • Google Gears (client-side persistence)
  • In Memory (if no SQL server is available on the client)
  • Adobe AIR (client-side persistence)
  • SQLite and MySQL (via Aptana Jaxer, the open source Ajax server)
  • additional environments (like HTML5) expected to come through working with the community on the project

ActiveRecord.js abstracts away underlying SQL commands so that JavaScript developers can have a unified API for storing, finding, selecting and retrieving objects and their data using the ActiveRecord pattern popularized by the Ruby on Rails community.

Here is some example code using the ActiveRecord.js framework; note that they’ve made some interesting changes away from how Ruby on Rail’s does the ActiveRecord pattern:

javascript
< view plain text >
  1. var User = ActiveRecord.define('users',{
  2. username: '',
  3. email: ''
  4. });
  5. User.hasMany('articles');
  6.  
  7. var ryan = User.create({
  8. username: 'ryan',
  9. email: 'rjohnson@aptana.com'
  10. });
  11.  
  12. var Article = ActiveRecord.define('articles',{
  13. name: '',
  14. body: '',
  15. user_id: 0
  16. });
  17. Article.belongsTo('user');
  18.  
  19. var a = Article.create({
  20. name: 'Announcing ActiveRecord.js',
  21. user_id: ryan.id
  22. });
  23. a.set('name','Announcing ActiveRecord.js!!!');
  24. a.save();
  25.  
  26. a.getUser() == ryan;
  27. ryan.getArticleList()[0] == a;

See the Aptana blog post for more details.

Related Content:

Posted by Brad Neuberg at 6:30 am
14 Comments

++++-
4.2 rating from 20 votes

14 Comments »

Comments feed TrackBack URI

i think i’ve replaced aptana with firebug. you know what would be really helpful? if someone just wrapped jslint in an eclipse plugin just so it could give me configurable line warnings.

the rest firebug provides.

Comment by ilazarte — January 14, 2009

Server side JavaScript is getting something serious, isn’t it?

Comment by frenchStudent — January 14, 2009

How does the security of this work? Client side SQL sounds like a disaster waiting to happen.

Comment by LewisWright — January 14, 2009

Implementing a HTML5-Backend might be harder than it seems because the API is async.
While it is no problem to make the existing APIs async (and might even be a good idea) I don’t know how you’d fit the HTML5 API into a synchronous programming model.
I made some experiments on my own pet OR-Mapper http://joose-js.blogspot.com/search/label/OR-Mapper
and the best I came up with were pseudo-synchronous method chaining interfaces. Are other ideas out there?

Comment by Malde — January 14, 2009

re: “How does the security of this work? Client side SQL sounds like a disaster waiting to happen.”

ActiveRecord.js works with Google Gears’, Adobe AIR’s, and eventually HTML’s client-side SQL stores. Thus security is handed by those, not by ActiveRecord.js directly.

On the server-side Aptana Jaxer provides the interface to instances of mySQL or SQLite running on the server.

Comment by khakman2 — January 14, 2009

@LewisWright, I ++ Kevin’s thoughts on who should handle the security. Data stolen from an XSS does seem like it would be a concern, but running a DB client side would never send any queries server side (you don’t even need a server), so we aren’t doing any thing extra crazy like executing arbitrary SQL commands over the network.

@Malde, you are absolutely right, it’s really hard! We are advocating that synchronous SQL calls be allowed from inside of asynchronous Web Workers. This still fixes the UI lock up problem, but allows us to use a sane API. I highly recommend everyone wanting this functionality get in touch with Ian Hixie (hixie.ch) and write the HTML 5 working group as well.

If this isn’t implemented, writing web apps that use SQL is not going to be a lot of fun, but we (and this library) will eventually adapt.

I do have some experimental unreleased code that handles the problem inside of this library. One of the solutions I came up with is a way to synchronize the order in which methods are called. What you could do is add the callback functions you need to pass to your sql queries to the stack.

ActiveSupport.synchronize(function(stack){
stack.add(function a(){});
stack.add(function b(){});
stack.add(function c(){});
},function d(){
//called when completed
});

b();
c();
a();

Functions are called in the order a,b,c and then d is called when there are no more items in the stack.

- Ryan

Comment by syntacticx — January 14, 2009

@LewisWright
Any time you do anything sightly more advanced then just passing data to server from client and vice versa you’re effectively creating business logic on the client. This *per definition* broadens the attack surface. I’ve tried to evangelize this point of view for more then 2 years now without success…
.
Still, good luck with AR for JS, it’s probably awesome, but I probably will never use it for the above reasons…

Comment by ThomasHansen — January 14, 2009

@ThomasHansen
If you’re not comfortable with storing data client-side, you can use it server-side. You can also use it client-side with in-memory persistence as a temporary store in conjunction with sending/getting data to/from the server :)

Comment by khakman2 — January 14, 2009

Hopefully PostgreSQL or at least ODBC for Jaxer is coming soon… both are available in the Mozilla code they use, but disabled at the compile level (at least outside Windows).

Comment by eyelidlessness — January 15, 2009

@syntacticx: I will certainly apply pressure as I have time w/ HTML5 folks, but as new products appear every day which make use of/require features which are still in draft (ActionScript, anyone?), sometimes you’re locked into supporting features/non-features you’d rather not.

Thus far I’ve avoided adding async capabilities to the JazzRecord ActiveRecord-style JS ORM (http://www.jazzrecord.org) for the same reasons, obviously. But the time is coming quite quickly where HTML5 will be deployed on numerous devices/runtimes, and at *least* the first generation of these will use the current draft of HTML. Webkit is among these, and it’s being adopted for use all over the place.

Being as though I want to support these devices/runtimes/browsers, I think it wise to make do with what we’re given and add support for asynchronous without dropping the existing, far more convenient, synchronous syntax. Biting the bullet might not be as hard as we’d like to think.

What makes it really aggravating is that we’re talking about JavaScript and SQLite for the most part. Neither is meant for “enterprise” amounts of data storage/handling. SQLite is extremely fast. A synchronous load of reasonable amounts of data at a time should be reasonable.

I’d love to think HTML5 will support both styles of querying, but my hopes are not high. W3C is quite slow to move on making change, and I don’t know that WHATWG is any better. I don’t have time to lobby.

-Nick Carter

Comment by thynctank — January 16, 2009

Are there extensibility points in this implementation? If i wanted to use another kind of storage medium (REST anyone), how hard is it to plug that in?

Comment by jaysmith — January 16, 2009

re: RESTful interfaces. Check out the ActiveJS repository at GitHub that also contains ActiveRecord.js. There you’ll see a Routes.js file that’s part of the bigger picture for the ActiveJS MVC which will, yes, support RESTful means of doing the same. Ask for more info on this in the ActiveJS Google Group too.

Comment by khakman2 — January 16, 2009

@thynctank I think I found a workable solution to use synchronous calls via ActiveRecord and still support the current asynchronous WebKit implementation. I still really want HTML5 synchronous eventually, but totally agree, it’s in the wild now and we need to support it. I’ll post the announcement in the ActiveJS Group when it is ready.

@jaysmith The JS part is easy, defining what the standard should be on the server for multiple server is the hard part. Want to start a topic in the ActiveJS Group?

Comment by syntacticx — January 16, 2009

@syntacticx Very cool, I’m all ears! Would certainly be interested in implementing something similar in JazzRecord.

Comment by thynctank — January 19, 2009

Leave a comment

You must be logged in to post a comment.