On 1/20/07, Guillaume Smet <[EMAIL PROTECTED]> wrote:
The fact is that once I fixed all this bugs in my local version, I
tried real inline batches and they have the classical problem
"StoredProcedure not an instance of AbstractWriteRequest". I wonder if
this code is really supposed to work and what it should really do. Is
it useful to fix this method or is there a major problem with the
global approach we should fix?
I've dig a bit more into the code to see if I could find an
explanation for this problem.
I've found 2 issues.
The first one is that RequestManager.statementExecute wraps the write
query inside a StoredProc and then calls loadBalanceStatementExecute
on this new StoredProc object. Finally it calls
RAIDb1.statementExecute which passes the STATEMENT_EXECUTE_TASK task
type to callStoredProc. With this task type, callStored proc waits for
an AbstractWriteRequest and it fails because we provide a fake
StoredProc object. There is definitely an inconsistency in this code
path and it should be fixed one way or another. I don't know this part
of the code so I prefer ask for an advice on how to fix this problem.
To have this problem I try to execute "insert into test values(10006,
'test test'); select * from test;" in the SQL console.
The second one is located in the SQL console code. In
VirtualDatabaseConsole.execSQL, the if
(request.toLowerCase().matches("^(\\(|\\s+)*select.*")) test is far
too simplistic and if I try to execute "select * from test; insert
into test values(10006, 'test test');", it uses statementExecuteQuery
instead of statementExecute. The problem is that statementExecuteQuery
does not have the code to deal with inline batches. Any idea on how to
fix this problem?
Regards,
--
Guillaume
_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia
