[Mulgara-general] Mulgara API's

[Alex Hall]

Paul Gearon wrote:

> Importantly, the server you send the command to is checking to see if  
> it knows the graph before handing it on to this resolver.  This means  
> a few things.  Most important is the fact that URIs for a graph need  
> not specify protocol, location, or service.  This is all done when you  
> establish a connection.  The URI becomes just a label for a graph.   
> (However, it is still possible to use a graph URL to find the server,  
> but this is for backward compatibility).

This seems to imply that graph URL's and URI's have been disambiguated. 
  Back when I was last working with this software, every graph URI was 
also a URL using the rmi:// protocol (for graphs stored on a Mulgara 
server, that is), and the URI was overloaded to be both a label and a 
locator.  Is this no longer the case?

> Another important thing is that you can force a particular server to  
> take your command, even if it is going to be passed on.  This can be  
> useful for all sorts of reasons (server visibility, efficiency in  
> distributed queries, etc).
> 
>> If memory
>> serves, the ItqlInterpreterBean was smart enough to determine the
>> correct server and open a session with it.
> 
> The ItqlInterpreterBean sucked.
> 
> The code in that class parsed its queries, and if it happened to  
> notice a graph URL while parsing it would automatically change  
> sessions, even though it was still in the middle of the parsing  
> operation.  Even if you provided your own session, it could still  
> arbitrarily change the session on you.  And all this was buried deep  
> in the parsing process.  I can't begin to tell you how unmanageable  
> this was.

Yes, I have seen some of this code, and I don't think the term 
"unmanageable" does it justice.

> For backward compatibility, the ItqlInterpreterBean is still there,  
> but now it works differently.  Now it parses a query into a command.   
> If the command is something that is to operate on a remote server,  
> then it interrogates the command for the URLs of the graphs it refers  
> to.  It then establishes new connections (caching old ones for the  
> current ItqlInterpreterBean) as needed, and issues commands on these.   
> If it is in a transaction, then any new connections are put into that  
> transaction as well.  When a transaction completes, then all servers  
> that have been spoken to during that transaction are informed that the  
> transaction is complete.  The whole thing performs faster, more  
> efficiently, and has greater functionality than the previous  
> ItqlInterpreterBean.

If I'm following you correctly, this means that processing a single user 
command can result in the ItqlInterpreterBean coordinating commands 
across connections to multiple servers.  If that's the case, that seems 
like a bit too much logic to have on the client side.  Am I missing 
something here?

>> Creating commands manually is probably the method I would prefer, if  
>> the
>> alternative is building up an ITQL string and then sending it back
>> through the parser.  You're right, this calling convention feels  
>> pretty
>> awkward.  If I decide to go down this route, I would certainly be
>> willing to take a look at refactoring that code.
> 
> Actually, it's just a matter of changing it to a visitor pattern.   
> Connections just need to implement an execute method for every Command  
> type, with the form:
> 
> Object execute(CommandImplementation cmd) { return cmd.execute(this); }
> 
> This is standard boilerplate visitor pattern stuff, and one of the  
> reasons I hate Java.  :-)
> 
> It would only take 10 minutes to do.  Maybe I'll do it in the morning.
> 
> (yes, these methods can be avoided by putting all the functionality in  
> a Connection class, avoiding the callback, but this does not use  
> encapsulation or information hiding, and makes for a monolithic class,  
> which is always a bad idea.)

Monolithic class, as in DatabaseSession? ;-)

Alex