512761 - Implement more natural javascript accessors for result rows

Status: ASSIGNED

(Toolkit :: Storage, enhancement, P3)

Description

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

I experimented with the async API a bit and found out that mozIStorageResultSet's getNextRow() returns only a mozIStorageRow, which only allows getting the result via getResultByName/Index. It would be quite handy if this could be a mozIStorageStatementRow from mozIStorageStatementWrapper.idl, so that I can directly access the results via js getters.

I'd also like to see this in 1.9.x so that I can use it in Thunderbird/Lightning/Sunbird.

Comment 1

[Shawn Wilsher :sdwilsh]

Changing getNextRow would break binary compatibility, so it's not really an option I'd be willing to consider unless there were serious problems with the current API.  However, we could add a language helper to accomplish the same thing, and would be much safer to take on branch (although the code has diverged quite a bit).

Comment 2

[Andrew Sutherland [:asuth] (he/him)]

The current plan is that Thunderbird is going to aggressively move to 1.9.2 once we ship 3.0 with 1.9.1.  By aggressively, I mean that after TB 3.0 ships and as soon as Firefox 3.6 ships we will move on a release, even if we have no new features.  The limited resources available to Thunderbird mean we cannot maintain a security branch by ourselves, so we will likely not have a lengthy supported end-of-life period and will just push everyone onto our 1.9.2 release.

This means Lightning will ideally come along for the ride.

Which is to say, I don't think it's worth the effort to make any enhancements to the 1.9.1 storage branch, especially given the extensive code divergence.

Comment 3

[Shawn Wilsher :sdwilsh]

This patch shouldn't be too hard to do.  It's going to require some refactoring to be able to share code for both the sync code and the async code, but I think it's worthwhile.

Comment 4

[Shawn Wilsher :sdwilsh]

Attachment: v0.1

I've got a patch that mostly does this, but I'm somehow making XPConnect dereference a garbage pointer.  Sadfaces.  Not sure why, and I don't have time right now to investigate it.

Turned out to be bigger than I expected too.

Comment 5

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

I'd still appreciate if someone could continue on this patch, obviously not for 1.9.2 though :-)

Comment 6

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Shawn, any chance you could look into this again?

Comment 7

[Marco Bonardo [:mak]]

I don't think Shawn will be able to look at this, though the wip patch is here, so someone may continue from where he stopped

Comment 9

[Marco Bonardo [:mak]]

I have an experimental webidl binding implementation of ResultSet, it still requires some work but it may do once ready.