[Mulgara-dev] ItqlIntepreterBean/TqlInterpreter/JTA

[Paul Gearon]

On Feb 5, 2008, at 9:43 PM, Life is hard, and then you die wrote:

>
> I've been looking at the latest mulgara in the jta branch (mgr-73
> branch), and hit upon some questions regarding the current
> ItqlInterpreterBean and TqlInterpreter.
>
> First of all, I see that ItqlInterpreterBean is deprecated; but it has
> been changed in incompatible ways (there is a compile-time
> incompatibility because of the getLastError() being renamed to
> getLastException(), and there are run-time incompatibilities too, i.e.
> the same app code that works with 1.1.1 doesn't work with trunk). Is
> ItqlInterpreterBean supposed to be backwards compatible?

Yes.  Evidently I was careless.  Sorry about that.  The unit tests  
that use ItqlInterpreterBean all passed, and I didn't go any further  
than that.

I'll change that method name back (I can't recall why I changed it - I  
must have been drunk with power).  Once that's done I'd appreciate  
finding out what old code doesn't work anymore (if it's just message  
and error strings, then I'm not too worried).

> Second, am I right correct in understanding that TqlAutoIntepreter is
> sort of interim replacement for ItqlInterpreterBean, but that the real
> move is for apps to start using Connection and TqlInterpreter instead?

Yes.  Don't you prefer this?  Everyone else I've spoken to thinks it's  
a better idea.  :-)

I mean, ItqlInterpreterBean actually established connections as a part  
of the query parsing process.  So getting a session was mixed in the  
SableCC code.  Call me old fashioned, but I think that idea just plain  
*%#$ed.

> Part of my questions are motivated by the need to get at the Session
> in order to be able to get the XAResourceC - TqlAutoIntepreter won't
> let me do that, and the ItqlInterpreterBean returns null for the
> session unless the session was explicitly passed in, so it seems the
> TqlInterpreter+Connection is the only way to go.

I have no problems with you adding an interface to TqlAutoInterpreter  
if you'd prefer to use this class.  However, since it can change to a  
new connection with every query, then it could get very hairy very  
quickly.  It already has to be careful to track every connection that  
it's trying to perform a transaction on.

However, the real way to manage the issue is to use TqlInterpreter and  
Connection, as you say.  The first is for turning query strings into  
Commands.  A Connection is something that can execute a Command.   
Hopefully this is easy enough to use.  If you find problems, then  
please let me know and I'll do my best to fix them.

Regards,
Paul