[Mulgara-dev] Backing up graphs

Life is hard, and then you die ronald at innovation.ch
Wed Jun 18 21:31:26 UTC 2008


On Wed, Jun 18, 2008 at 02:40:52PM -0400, Alex Hall wrote:
> Paul Gearon wrote:
> > On Wed, Jun 18, 2008 at 9:10 AM, Alex Hall <alexhall at revelytix.com> wrote:
> >> The backup operation currently checks for the presence of a fragment
> >> component in the source URI when deciding whether to back up an
> >> individual graph or the entire database.  This depends on all graph
> >> URI's being relative to the server URI, which is no longer the case.  As
> >> a result, it is not possible to back up a graph that has an opaque URI
> >> that is not relative to the server URI; the backup operation treats this
> >> as a backup of the entire database.
[snip]
> >>  I see two possible approaches to fix this:
> >>
> >> 1. Look for the given source URI in the system graph; if it is found
> >> there then treat the backup as a graph backup, else treat it as a server
> >> backup.
[snip]
> > I prefer the first as well, but I see other reasons for it beyond what
> > you've already said. We only have a duty to back up the data that we
> > are storing. I don't think we should be performing backups of data
> > that is accessible with the D2R resolver, the http resolver, etc. As
> > such, we should be looking for those entries in the system graph that
> > have the correct graph type (so we avoid anything that gets mapped to
> > a resolver, like Views or the XSD resolver).
> 
> If we're talking about backing up the entire server, then I agree that 
> we only have the duty to back up what's actually stored in the database.
> 
> When it comes to backing up an individual graph, the distinction is less 
> clear.  Backing up a graph is implemented by resolving the constraint 
> [$s $p $o <model>] so we have the ability to back up any type graph 
> whose resolver is able to evaluate that constraint.  Not every resolver 
> supports this type of constraint (Lucene and XSD come to mind as two 
> types that do not).  However, restricting graph backups to only graphs 
> of type mulgara:Model might prevent potentially useful operations; for 
> instance, I could see the usefulness of exporting the contents of a 
> View.  So once again I see several approaches:

I agree - it should be up to the resolvers to determine if a
particular graph can be exported or not.

> 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 second option seems the simplest and "automatic"; but 3 will work
too.


  Cheers,

  Ronald




More information about the Mulgara-dev mailing list