[redland-dev] Redland contexts vs named graphs

[Michael Stahl]

On 10/10/2010 22:17, michael wrote:
> Redland does not directly support named graphs. Instead, named graphs can be implemented by clients using Redland's 
> context facility. I've been trying to do this and have been running into difficulties.
> 
>  From the release notes for 0.9.17 [1]:
> 
>    * Check that duplicate statements are not added to models with the librdf_model_add_statement and
>      librdf_model_add_statements methods.
>    * The methods for adding statements with a context do not check.
> 
> While adding statements to the model without a context will not introduce duplicates, if a model contains any statement 
> with a context, duplicates may be returned. So the duplicate restriction to *adding* statements via the 
> librdf_model_add_statement(s) methods is misleading because it does not ensure that a model will not *return* 
> duplicates. To ensure uniqueness, clients must examine each statement, skipping those with a context set. Sometimes this 
> is not even possible for functions like librdf_model_size or any other function that does not accept a context argument.

[snip]

you're not the first one to notice; see here:
http://lists.usefulinc.com/pipermail/redland-dev/2008-April/001748.html

attached to that you may find a patch for the "hashes" and "memory" stores
that adds checks in order to not insert duplicate statements.
because i am only interested in in-memory stores that is sufficient for me.

but i'm not actually using that patch anymore; because downstream Linux
distro maintainers complained about the patches in our bundled redland
library, and it is apparently impossible to have patches to redland
merged, i have had to conclude to work around redland deficiencies in
client code (in this case, by an explicit check that a statement to be
added is not already in the store).

regards,
 some other michael

-- 
"The thing that really convinced me that C++ was a language whose time
 had passed was reading Scott Meyers' books Effective C++, More
 Effective C++ and Effective STL, which could be seen as a long list of
 gotchas and workarounds that must be borne in mind when writing C++.
 Any language that required you to deal with this nonsense on a daily
 basis was clearly wasting its users' time." -- Miles