[Mulgara-dev] Backing up graphs

Paul Gearon gearon at ieee.org
Thu Jun 19 05:30:12 UTC 2008


On Jun 18, 2008, at 1:40 PM, Alex Hall wrote:

<snip/>
> So once again I see several approaches:
>
> 1. Only allow backing up graphs of type mulgara:Model.
>
> 2. Back up any graph contained in the system graph regardless of type;
> if the resolver doesn't support resolving a constraint with  
> variables in
> the subject, predicate, and object positions then it will throw an
> exception.
>
> 3. Add a supportsExport() method to the ResolverFactory; any graph  
> type
> that returns true for this method is required to resolve the  
> constraint
> [$s $p $o <model>].
>
> I think that the first option is the safest approach in that we can  
> only
> guarantee exportability for graphs of type mulgara:Model.  The third
> option is the cleanest approach if we wish to extend export capability
> to graph types other than mulgara:Model.

The first option is the easiest, but ignores other backups that may be  
validly requested from other graph types. The memory graphs, for  
instance.

The second is a bad idea for those graphs that can't handle the ($s $p  
$o <graph>) constraints, especially those that are calculated, such as  
data range resolvers. At the moment, the only way we have of handling  
resolvers that don't do that kind of query is to throw an exception.

The third approach seems like the best to me.

>> However, on thinking about this, I see a deeper issue.....
>>
>> Server backups and graph backups are two unrelated operations that
>> happen to share a name. Graph backups are performed by writing out a
>> graph to an RDF file. In this case, they're more of a "save" or
>> "export" operation. Database backups, on the other hand, create a
>> binary file that contains a representation of the internal structures
>> that Mulgara uses. These files can be loaded with a "restore"  
>> command,
>> while graph backups are loaded with a "load" command. There's an
>> unnecessary conflation here, and I think that the proposed "fixes"  
>> are
>> just hiding it.
>
> The conflation of server backup and graph export has bothered me as
> well.  However, even if we separate the two operations, I think the
> previous conversation about which graph types to support for exporting
> is still relevant.

Yes, and I mentioned this.

>> At the risk of creating incompatibilities, I advocate dropping the
>> ability to back up a graph, and the introduction of an "export"
>> command to replace it.
>
> Agreed.  Seems like it should be a fairly straightforward  
> modification;
> the toughest part is probably going to be updating the TQL grammar and
> interpreter.  As long as we're breaking backwards compatibility, now  
> is
> probably the time to go ahead and do it while we are still in alpha.

It would be up to beta already, if only I were actually working right  
now. I expect to start again by next week.

Regards,
Paul Gearon



More information about the Mulgara-dev mailing list