count_quad_estimate not accessible from TripleModel

[kjetilk]

Here's a test case where a test for using count_quad_estimate (and holds) fail for TripleModel.

They should work right of the box, as the methods should be there from the role?

[kasei]

It looks like the issue here is that we never exposed count_quads_estimate in the model, only the store. I'm happy to expose that at the model level, but I think it needs to be better defined before we proceed. For example, if you want to use count_quads_estimate to implement holds, then the estimate function must return either the exact count or an overestimate. If it can return an under estimate, then it might return 0, in which case the semantics of holds break. Are you ok with that?

[kasei]

I'm thinking of something like this as the documentation:

=item C<< count_quads_estimate( $subject, $predicate, $object, $graph ) >>

Returns an estimate of the number of quads in the model matching the supplied
pattern (using the same matching semantics as C<< get_quads >>). This estimate
is guaranteed to non-zero if the count returned from an equivalent call to
`count_quads` would return a non-zero result.

[kjetilk]

I'm thinking of something like this as the documentation:

=item C<< count_quads_estimate( $subject, $predicate, $object, $graph ) >>

Returns an estimate of the number of quads in the model matching the supplied
pattern (using the same matching semantics as C<< get_quads >>). This estimate
is guaranteed to non-zero if the count returned from an equivalent call to
`count_quads` would return a non-zero result.

Yeah, I think that formulation is good, even though I'm not sure we need to require it should always return an overestimate? The only strict requirement is that it should return a non-zero result if count_quads would return a non-zero result, right?

Also, we don't necessarily have to connect holds to count_quads_estimate, it just seemed like a reasonable default.

[kasei]

@kjetilk Do you think this is good to merge, now?

[kasei]

@kjetilk And does merging this clear the path for #123 to be merged?

[kjetilk]

Yeah, I think we're good to go for both :-)