Changes: Only filter on value, not rdf:type when inserting foreign keys
authorAdrien Bustany <adrien.bustany@nokia.com>
Mon, 3 Oct 2011 13:58:03 +0000 (16:58 +0300)
committerMathias Hasselmann <mathias@openismus.com>
Wed, 5 Oct 2011 13:45:59 +0000 (15:45 +0200)
commitc0b7515af73f633821e347dec921ef3e35f300b2
tree2c9c85803dc1459bd49367f2b4b5a64ac721f1bf
parentd8f201468c7e035b2acca6f9f62e1b1ea3ea829b
Changes: Only filter on value, not rdf:type when inserting foreign keys

RevBy: cocos (MR#286)
Details:
When inserting a foreign key for predicate foo:bar (say idenfitied by
its nie:url, the query generated looks like (where YYY is the union of
the range of foo:bar and the domain of nie:url):

INSERT {
  _:foo a YYY; nie:url "value"
} WHERE {
  OPTIONAL { ?foo a YYY; nie:url "value" }
  FILTER(!bound(?foo))
}
INSERT {
  <urn:xxx> a nco:PersonContact; foo:bar ?bar
} WHERE {
  ?bar nie:url "value"
}

This breaks if:
1. The foreign key predicate is an inverse functional property (like
   nie:url)
2. The value "value" is used for two different predicates with different
   domains (for example, nco:photo points to a nie:InformationElement
   while maemo:contactAudioRingtone points at a nfo:FileDataObject)
3. The two predicates are used successively (for example, inserting a
   ringtone, then an avatar with the same nie:url).

In that case, when running the query for the second query, the OPTIONAL
in the INSERT of the foreign key will not match, so the FILTER will
return true and the INSERT run, violating the inverse functional
property constraint.

The proposal to solve this is to filter only in the foreign key
predicate in the OPTIONAL, and not additionally on rdf:type. This is
consistent with what is done in the actual INSERT where the contact is
saved.
src/engine/contactsaverequest.cpp