Closed Bug 394732 Opened 13 years ago Closed 4 years ago

Create js-friendly API for mozstorage


(Toolkit :: Storage, defect)

Not set





(Reporter: axel, Unassigned)





(3 files, 4 obsolete files)

I'd like to see an object-relational-mapping for js and mozstorage. Say, something like sqlachemy does. Using JS1.7 iterators and generators, that should be totally feasible. That is, for someone that knows SQL, which is not me.

Rich showed interest in my blog, I hope that's the right Rich I'm CCing. CCing jresig for some js library API insight.

This might start out as an extension-provided jsm, given our current 1.9 timeline.

I'm not sure I care about C++, I wouldn't want to do compromises for that, though.

As for the actual API, sqlalchemy uses a lot of named params, would js objects as params be a good replacement? John?
At the very least we should be able to use classinfo to allow access to parameters and results using normal JS object syntax instead of xpcom methods, even if it's only for numeric indices.
Thanks Axel - you got the right Rich.

The attached JavaScript code shows what a fairly faithful port of SQLAlchemy might look like. I've translated the SQLAlchemy tutorial's example Python code into JavaScript code, making changes only where necessary. You can see the original here:

Some notes:
- As suggested by Axel, objects with properties are passed as a substitute for keyword arguments.
- I haven't used SQLAlchemy before, so I may have misunderstood how some things work. :-)
- SQL relations use explicit functions rather than operator overloading. eg jsa.eq(a, b) rather than a == b.
- Please excuse syntax errors, etc - I'm just posting this code to get the ball rolling.

Axel, is this what you want the ORM library to look like?
Comment on attachment 279545 [details]
Translation of SQLAlchemy tutorial v1

Sorry, lost track of this in my inbox.

Yes, this is pretty much what I had in mind. I just ran across elixir, too, but that may be (as with sqlachemy) be a solution on top.

I'm really interested in the table creation part and the query_by.

I'd like jresig to look at this, too, from an js-api point of view. John, I'd think that filter_by with kwargs is fine if filter() works like js array extras? That'd be the kind of wisdom I'd like you to provide.

Basically, we should divert from wherever js 1.6-8 array extras suggest so. Right?
Attachment #279545 - Flags: review?(jresig)
This is on my radar for moz2
Wouldn't it make sense, to add something on top of it like Elixir? 

Also, while doing Django development, I found the Django's query_sets to be very sexy. To get a list of all the items in a table named "News", sorted by the date "created" one creates a (Python)dictionary á lá:

latest_news_list = {
	'queryset'   : News.objects.all(),
	'date_field' : "created"

See for documentation on the API, that produces News.objects.all()

I think it may be nice to offer a layer, that takes away verbosity.
Note: Bug 429986 is being designed such that JS is much nicer to work with (see test cases for sample code).
bug 452987 helps a bit
Depends on: 452987
sdwilsh: it does? ;)
Attached file WIP django.db style javascript ORM (obsolete) —
This is no doubt very naive and bug ridden, just trying to flesh out some ideas and functionality I miss from django.db

Joins are not even supported yet, etc... I would like some feedback.
a couple of tests are broken and disabled. very much a WIP.
(In reply to comment #10)
> Created an attachment (id=366632) [details]
> WIP django.db style javascript ORM 
API seems a bit foreign/strange to me.  Especially the constraints for selects; those seem really unnatural.

I also think it might be more interesting to have Orm (which should be ORM) to take an object, so you can do something like:
new ORM({database: nsIFileRepresentingDB, models: allModels});
- or -
new ORM({inMemory: true, models: allModels});
- or -
new ORM({connection: mozIStorageConnectionToRepresent});
It is foreign, somewhat Pythonic, very truncated. The docs at are a quick read:

I like the conciseness, however, the main issue is fast and easy CRUD. I have been writing a lot of Python in the past few years. It does make sense to make this more "Javascripty". I think the onject as argument is smart as well, and I was planning on supporting that as well. If we can only support a single approach, lets use objects as they are more self-explanatory. 

I'll keep hacking on this - I want to add JOINS including 'many to many'.
Still have NOT addressed sdwilsh's naming conventions - posting for dietrich to check out.
Attachment #366632 - Attachment is obsolete: true
Attached patch forgot the makefile (obsolete) — Splinter Review
Attachment #367642 - Attachment is obsolete: true
sdwilsh: Just curious if there is anything I need to do for the database connection to work in a storage xpcshell test where the sqlite db is on the filesystem. If i run this test with my connection to an "In Memory" database, it works.

Btw: how is the naming and the location in storage?
Attachment #366633 - Attachment is obsolete: true
Attachment #367895 - Attachment is obsolete: true
The weird thing is that when you run the test file test_storage_JSORM_field_model.js, certain tests fail that instantiate a new Model(). Usually, it is a test that creates a new Model with a different table and columns as the previous test.  If you run the test by itself, it passes. The "fields" property seems to live on in future objects. SO WEIRD. perhaps I am doing something totally wrong, I do not know.
No longer depends on: 452987
Attachment #279545 - Flags: review?(jeresig)
Let's be realistic, this is unlikely to happen. The best thing we have is Sqlite.jsm, and if we can get bug 512761 it won't be that bad. We can still improve that clearly.
Closed: 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.