Synchronous retrieval

[micapam]

Sorry for raising a ticket on this, as it's a question rather than a bug - if there's a mailing list that would be better for these types of questions please let me know.

What I'm wondering is whether it's possible to do synchronous retrieval of records using AS3-Spod. The interface for my class that I'm trying to implement using AS3-Spod has methods like this:

function getAllUsers():Vector.<User>;

Now I can see that SpodTable has a selectAll() method. But I can't see how I can access the data without listening to signals - and if I have to listen to signals, then I can't do everything in the body getAllUsers method, and return the retrieved the data, can I? Unless I'm misunderstanding something about how it works.

This being the case, why would one ever call SpodManager's open() method without the second argument (async) being true?

[micapam]

Another related comment about the signals. Since I'm assuming I can't implement synchronous methods, I'm considering taking another approach. I'll try to explain as concisely as possible, without getting into too much implementation details.

I need to call a the selectAll() method on a my "users" table object (a SpotTable instance), and then handle the result. I'm using Robotlegs' CommandMap.detain() and CommandMap.release() to implement an asynchronous Command. From looking at AS3-Spod's source code, looks like I should listen to SpodTable.selectAllSignal. I'm using a Promise (Robotlegs Oil extension) to guarantee that I get some kind of result for my asynchronous command.

If the query executes successfully, no problem. I can clean up the listeners, release my command, etc. The problem comes in if the query fails for whatever reason. How do I listen for that? Looks like I have to listen to SpodManager.errorSignal. But, unless I'm misunderstanding the source code, that's basically a global error signal, which means all of AS-Spod related commands will have to listen to that signal. I seem to have a choice of three options, none of which are good ones:

1. Listen to SpodManager.errorSignal - and thus risk a scenario in which one SQL error fails all the asynchronous Commands currently detained (i.e. waiting for a result).
2. Don't listen at all for errors. This means that any SQL errors will be ignored and I won't be able to guarantee that my Commands will be released: breaking the Promise.
3. Listen to SpodManager.errorSignal, and somehow try to parse whether or not it's relevant by examining the associated SQLError. As well as being hacky, this would mean my Promise would have to be aware of what Command it's related to - breaking encapsulation (and maybe potentially preventing GC from cleaning up properly?)

Does that make sense? Or have I totally misread the source code?

[stickupkid]

You are correct in thinking that you can't use the database synchronously except for open, but to answer your question about why you would want to, the documentation states:

"The operations of creating and opening the database, as well as all other operations that are performed using this SQLConnection instance (including statement execution and other operations performed by a SQLStatement instance associated with this SQLConnection instance) are performed synchronously when the database is opened using this method."

I think you should raise a feature request to surface statement errors easier. I am catching them, the issue is that they're not easily accesible for you.

[stickupkid]

There are two ways I think we can do this...

1. Instead of returning a signal for "selectSignal" for instance we return an Operation, which will have a successful and unsuccessfull signal.

object.tableRow.table.select.successful.add(handleSuccessSignal);
object.tableRow.table.select.unsuccessful.add(handleErrorSignal);

2. To prevent breaking compatibility we have

object.tableRow.table.selectSignal.add(handleSelectSignal);
object.tableRow.table.selectErrorSignal.add(handleSelectErrorSignal);

I actually prefer number 1, but it would break existing code bases BUT because we're not a version 1.0 I think we should be fine. See Semantic Versioning concerning:

Version 1.0.0 defines the public API. The way in which the version number is incremented after this release is dependent on this public API and how it changes.

Note: didn't mean to close the ticket, "Markdown" link is way to close to "Close issue"

[micapam]

Sounds great. I like solution 1 as well. Perhaps I could work on this in my fork?

I'm wondering, though, which Operation class you mean. Do you mean to create a new class called Operation? I'm hoping you don't mean any of the mx.rpc.* ones, as something that makes AS3-Spod great for me is the fact there are no dependencies on Flex (I'm working on an AS3 project with no Flex dependencies at the moment).

[stickupkid]

I was thinking of just an interface IOperation which is a standalone class, it would just have two getters one called successful and unsuccessful.