[Mulgara-general] execute command doesn't seem to work

Alex Hall alexhall at revelytix.com
Thu Aug 13 13:46:45 UTC 2009


Paul Gearon wrote:
> On Wed, Aug 12, 2009 at 1:15 PM, Alex Hall<alexhall at revelytix.com> wrote:
>> Hmm... I'm taking a closer look at this problem.  It's not going to be
>> trivial to fix.  The ExecuteScript command is trying to use the
>> connection passed in from the interpreter to execute each command in the
>> script.  The interpreter, in turn, uses the server URI that it gets from
>>  the ExecuteScript command to create the connection (or re-use an
>> existing connection).  The ExecuteScript command, being a local command,
>> does not know any server URI so it gets a dummy connection with a null
>> session, hence the NullPointerException.
> 
> OK, so what if the ExecuteScript command ignores the connection that
> it's given and creates connections of its own?

I think it's going to have to do that.  The question is, what is the
expected behavior if an execute command is issued in a TQL shell inside
a transaction, such as:

$ set autocommit off;
$ execute <file:/tmp/MyScript.tql>;
$ ... other commands ...
$ set autocommit on;

If it's expected that none of the commands in the script are to be
committed until the transaction is committed by the shell, then it isn't
going to be sufficient for the ExecuteScript command to create its own
connections.  It will have to get them from the shell.

>>From memory, we're sending the entire command to the server... is that
> right? If so, then we'd have to do the parsing at the client end
> and..... err, it's looking messy already. Sigh.

We are already parsing on the client end, but we're taking an overly
simple approach.  The ExecuteScript command opens the script file, reads
one line of input, parses it with an interpreter, and executes the
resulting command with the connection that it was given.  So yes, it
will take some work to get the parsing right.

Alex



More information about the Mulgara-general mailing list