Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SPARQL Update Part 2: DeltaTriples #1429
SPARQL Update Part 2: DeltaTriples #1429
Changes from 1 commit
4abca8d
9c4f476
1fc6e24
6d5c6b8
e694264
ae7742c
47d0e95
a24470a
e5268f7
e34d016
2fd5ff9
bb27cea
826f17c
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
Check warning on line 32 in src/index/DeltaTriples.cpp
Codecov / codecov/patch
src/index/DeltaTriples.cpp#L32
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't it true that the
blockData()
already lives inside theLocatedTriple
, and thekeyOrder
should be a member of theLocatedTriple
.On the other hand I currently have forgotten, which state for more than one triple is stored in the
LocatedTriples
at all...There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I think I know what I want to say:
The
LocatedTriples
should know about the above members,and then you immediately call a function
locatedAndAdd
on that object, which gives you back the handles and basically does the two steps that are performed here.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mostly don't understand what you want to say here.
getAugmenteMetadata
is already present, but doesn't work yet because it is not initialized. This will be part of the integration.LocatedTriple
should the Permutation to which it belongs?LocatedTriplesPerBlock
manages allLocatedTriple
s for a permutation.DeltaTriples
does the management ofLocatedTriplesPerBlock
for all permutation and exposes an interface that is no longer concerned with individual permutations. For this it needs the handles for all the permutations of each triple. How exactly do you propose to move this intoLocatedTriples
?Check warning on line 166 in src/index/DeltaTriples.cpp
Codecov / codecov/patch
src/index/DeltaTriples.cpp#L166
Check warning on line 187 in src/index/DeltaTriples.cpp
Codecov / codecov/patch
src/index/DeltaTriples.cpp#L187
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it a good idea to make this mutable getter public?
It lets us introduce very very very nasty bugs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Made it private for now.
Mutable LocalVocabs are used in LocatedTriples and the execution of normal queries (though these are currently temporary). These two need to be in sync for the retrieval of IDs while querying. The temporary IDs that a generated while querying (e.g. Service) can be discarded. Given the constraints I decided on a single global LocalVocab. This is a point that is still open for the integration PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes,
I think that issues like "how do we clean up the local vocab, when the inserted entries are not needed anymore"
Can be postponed to the future, as it is probably related with the question "how do we deal with concurrent updates" (in particular updates that run concurrently with queries.).
Check warning on line 75 in src/index/DeltaTriples.h
Codecov / codecov/patch
src/index/DeltaTriples.h#L75
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Again, what do we need the mutable access for (other than testing, where a friend would be a better option, and often not even that is needed).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're right. The mutable accessor is only used internally. To avoid switching between public and private methods I have inlined the 3 calls to it.