[Mulgara-general] Mulgara as embedded engine

[Paul Gearon]

On Dec 13, 2007 5:27 PM, Peter Becker <peter at peterbecker.de> wrote:
> Hi Paul,
>
> maybe the problem with me not finding the documentation I am looking for (note
> that I am not saying you lack documentation in general, just for my use case)
> is that the feature I am looking for is not really there. I guess JRDF would
> be the one to go -- but as you said it is broken and while the JavaDoc might
> be ok it seems to lack introductory material.

Well, I *thought* JRDF was broken, but Andrae says it's back to
working again (yay!).  I notice that Edwin is using it, as has Robert.

> If I understand you right what you recommend is using the same approach as
> JDBC: just grab a data source using some API and then switch to a different
> language (SQL or TQL). It's not what I was looking for since that lacks
> typesafety

Ah, so you're not a Ruby fan?  :-)

Yes, Answers can't give you typesafety, but at least you know there
are only 3 types: Literals, URIReferences and BlankNodes.  That's the
beauty of RDF.

> and editor support (no Ctrl-Space for you, buddy ;-) And no
> inline-documentation. And no syntax highlighting. Of course you can't
> refactor things automatically! ). At least you guys don't claim the approach
> is useful across multiple data sources as JDBC sometimes seems to do :-)

I'll confess that I've never liked the paradigm of inlining query
strings in my source code (it's bad enough in Java, but in C it
positively gives me nightmares).  I sometimes think that the last 20
years of frameworks have been little more than a series of attempts to
separate the query code out of the source.  :-)

> Since I will need only a small subset of the features I might go and write my
> own wrapping code to hide the strings away, though -- after all I will need
> only basic query expressions and no writing.
>
> Regarding the source in Eclipse: I see your problem with the generated code. I
> have a Mulgara project set up, so I will try to extract the sources from that
> one.

Just remember to build the project with Ant first.  That way all the
generated files will have been constructed.  The modification to the
script I gave you should work fine.  (Running it from the base
directory of Mulgara, rather than from src/jar).

> PS: a question still open: do I need to specify a directory or is there an
> option to run Mulgara in-memory only?

It can be run in memory only, but you have to set the configuration
before building it.

If you go to conf/mulgara-config.xml you'll find the following:
  <!--
    Implementations of the persistent and temporary node pools, string pools,
    and resolvers.  The persistent resolver is used to manipulate the system
    model.
  -->
  <PersistentNodePoolFactory
class="org.mulgara.store.nodepool.xa.XANodePoolFactory"
dir="xaNodePool"/>
  <TemporaryNodePoolFactory
class="org.mulgara.store.nodepool.memory.MemoryNodePoolFactory"/>
  <PersistentStringPoolFactory
class="org.mulgara.store.stringpool.xa.XAStringPoolFactory"
dir="xaStringPool"/>
  <TemporaryStringPoolFactory
class="org.mulgara.store.stringpool.memory.MemoryStringPoolFactory"/>
  <PersistentResolverFactory
class="org.mulgara.resolver.store.StatementStoreResolverFactory"
dir="xaStatementStore"/>
  <TemporaryResolverFactory
class="org.mulgara.resolver.memory.MemoryResolverFactory"
dir="tempStatementStore"/>

What you want to do is to change the class attribute of each of the
"PersistentXXXFactory" elements to the memory version instead of the
xa version.  Once this is done, rebuild the distribution (./build.sh
dist).  By doing this, all the internal state information (such as
which models you have created) is now being stored in memory, and not
on disk.

However, any models you try to create will still default to the "on
disk" type.  So to overcome this, make sure you add
<http://mulgara.org/mulgara#MemoryModel> to the end of any "create"
statements.  Once you've done this, everything should be in RAM.

Paul