queryToken and PgUrl parse changes

[dougarthur]

Here are the changes I made for passing around queryToken and parsing the db url I needed.

[msakrejda]

(sorry about the delay--life got in the way)

So I've incorporated the fix for the URL parsing. For the moment, I've decided to include it as-is, since as far as I can tell, the only limitations on PostgreSQL database names are that they start with a letter and are 63 characters or less).

The token stuff I'm not sure about. If you look at what I did in pgconsole, I wrap the Connection in a service which instantiates a new result handler for every query execution. This way, the handler instance itself knows what query it is dealing with, and the query token would only be necessary to try to map the handler to any errors / warnings that come up as a result of the query (the PostgreSQL protocol only loosely ties these to the query, so I didn't want to add this as an aspect of the result handler, especially since you may need to deal with errors that are not directly caused by queries).

However, it might make sense to provide this information to the handler anyway... Can I ask how your handlers are using the QueryToken, and how you map this back to the original query submitted?

[dougarthur]

I think about the queryToken in terms for an AsyncToken request on a
remoteObject. Attached to the ResultEvent, you get the original token
back. That was my initial thought around it. I had not looked at the
console, so I didn't consider doing it the way you're doing it there,
but it would seem it would be a bit more work to accomplish that. I'll
take a look at that over the weekend, if I have time.

The way I'm using the tokens is to track each query, and put them in
an array so that I can cancel queries that have not completed
execution if a stop was called. Since the connection.cancel() method
takes a token, I needed a way to know which queries had completed its
execution. I may queue up 100+ queries, b/c it's a replay tool, and
the rate can be dynamically set. Literately thousands of requests per
second, or just as little as only a few requests per hour.

        private function stopReplayData():void {
            if (_isReplaying) {
                if (_timer && _timer.running) {
                    _timer.stop();
                    _timer = null;
                }

                var token:QueryToken;
                var i:int;
                for (i = _queryTokens.length - 1; i >= 0; --i) {
                    token = _queryTokens[i];
                    _conn.cancel(token);
                }

                _isReplaying = false;
            }
        }


       private function

queryCompleteHandler(event:QueryCompletionEvent):void {
var token:QueryToken;
var i:int;
for (i = _queryTokens.length - 1; i >= 0; --i) {
token = _queryTokens[i];
if (event.token == token) {
_queryTokens.splice(i, 1);
}
}
}

• Doug

On Thu, Mar 8, 2012 at 1:58 PM, Maciek Sakrejda
[email protected]
wrote:

(sorry about the delay--life got in the way)

So I've incorporated the fix for the URL parsing. For the moment, I've decided to include it as-is, since as far as I can tell, the only limitations on PostgreSQL database names are that they start with a letter and are 63 characters or less).

The token stuff I'm not sure about. If you look at what I did in pgconsole, I wrap the Connection in a service which instantiates a new result handler for every query execution. This way, the handler instance itself knows what query it is dealing with, and the query token would only be necessary to try to map the handler to any errors / warnings that come up as a result of the query (the PostgreSQL protocol only loosely ties these to the query, so I didn't want to add this as an aspect of the result handler, especially since you may need to deal with errors that are not directly caused by queries).

However, it might make sense to provide this information to the handler anyway... Can I ask how your handlers are using the QueryToken, and how you map this back to the original query submitted?

---

Reply to this email directly or view it on GitHub:
#15 (comment)