[Mulgara-general] Mulgara API's

[Alex Hall]

Hi Paul,

Paul Gearon wrote:
> Are you connecting to Mulgara in the same JVM, or as a remote process?
>   

Well, the existing software runs as a webapp inside Tomcat, which would 
seem to dictate that we connect to Mulgara as a remote process.  This 
just seems like a better idea in general in order to allow for future 
growth, federation, etc.

>  If it's in the same JVM, then you can continue to use a session.
> Otherwise, I recommend moving to using Connections (these wrap
> sessions).  Unfortunately I haven't had time to document them yet.
> :-(
>   

What benefits does using a Connection have as opposed to using a 
SessionFactory to get a remote session to the server?

> The basic idea of the interface is to create a connection to a running
> database.  You can then execute commands on this connection.  A simple
> example (without exception handling) is:
>
> Connection conn = new SessionConnection(URI.create("rmi://hostname/server1"));
>
> Interpreter interpreter = new TqlInterpreter();
> Command cmd = interpreter.parse("insert ......... into
> <rmi://hostname/server1#data>;");
> cmd.execute(conn);
>   

What happens in this case if you try and execute a command to insert 
into a server other than the one you opened a connection to?  If memory 
serves, the ItqlInterpreterBean was smart enough to determine the 
correct server and open a session with it.

> cmd = interpreter.parse("select $x from <rmi://hostname/server1#data>
> where $x $y $z;");
> Answer answer = (Answer)cmd.execute(conn);
>
>
> You can also manually create Commands if you want to do that instead
> of using iTQL:
>
> new SetAutoCommit(false).execute(conn);
> new Load(fileUri, modelUri, false).execute(conn);
> Command c = new Commit();
> c.execute(conn);
> new Load(fileUri2, modelUri, false).execute(conn);
> c.execute(conn);
>
>
> Yes, this looks a little backwards (Ronald pointed out that it should
> look like connection.execute(command)).  I'll have to look at this,
> but for the moment it works.
>   

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.

Thanks,
Alex

> A more complete example (including the use of the connection factory)
> is in org.mulgara.itql.TqlAutoInterpreter.
>
> Paul
>
> On Thu, Feb 21, 2008 at 3:19 PM, Alex Hall <alexhall at revelytix.com> wrote:
>   
>> Greetings All,
>>
>>  I am picking back up with Mulgara after a couple of years on other
>>  projects.  We are in the process of replacing the existing Jena backend
>>  to our software with Mulgara, so we will need fine-grain, programmatic
>>  control over creating models, importing data, inserting/deleting
>>  triples, executing queries, etc.  Is the Session API still the
>>  recommended interface to use for these purposes?
>>
>>  Thanks,
>>  Alex
>>  _______________________________________________
>>  Mulgara-general mailing list
>>  Mulgara-general at mulgara.org
>>  http://mulgara.org/mailman/listinfo/mulgara-general
>>
>>     
> _______________________________________________
> Mulgara-general mailing list
> Mulgara-general at mulgara.org
> http://mulgara.org/mailman/listinfo/mulgara-general
>