[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