Adding 'only_inverse' parameter to Resource.load()

[Pēteris Caune]

Hi All,

I'm thinking of adding 'only_inverse' optional parameter to
Resource.load() method, for optimization purposes.

Resource.load() currently loads all direct and inverse attributes for
a given resource, and is very handy.
When using sparql_protocol plugin, this results in two SPARQL queries
getting executed.

I'm looking at optimizing client code and trying to cut down on number
of SPARQL queries executed. In cases I know inverse attributes won't
be accessed, and I'd like to be able to load just the direct
attributes.

It would work like this:
some_resource.load() <-- same as now, loads direct and inverse
attributes in two queries
some_resource.load(only_direct=True) <-- loads just direct
attributes, one query

On implementation side, it would then make sense to replace
Resource.__full boolean flag with Resource.__full_direct and
Resource.__full_inverse to keep track of what's loaded.

Any objections?

[Cosmin Basca]

Hi Peteris,

Since SuRF distinguishes between direct and indirect RDF attributes, I agree with your proposition. My only "objection" :) would be related to naming of the parameter. I feel that calling 

some_resource.load(inverse=False) feels cleaner and is just as expressive as calling some_resource.load(only_direct=True), in addition the "inverse" attribute should be set to True by default, to keep SuRF contract API consistent.  What do you think?

Cheers,

Cosmin

[cuu...@gmail.com]

Hi Cosmin,

yeah, "inverse" is shorter and looks cleaner than "only_direct". I
propose "only_direct" because it's already used in attribute queries
like:

somebody.foaf_knows.full(only_direct=True)

http://packages.python.org/SuRF/modules/resource/result_proxy.html#surf.resource.result_proxy.ResultProxy.full

Peteris

> --
> You received this message because you are subscribed to the Google Groups
> "surfrdf" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/surfrdf/-/Yjv6vVc4u5sJ.
>
> To post to this group, send email to sur...@googlegroups.com.
> To unsubscribe from this group, send email to
> surfrdf+u...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/surfrdf?hl=en.

[Cosmin Basca]

You are absolutelly right Peteris, I would then disregard my naming "suggestion" :]

Cheers,
Cosmin

[cuu...@gmail.com]

And, it's done: http://code.google.com/p/surfrdf/source/detail?r=373#

> --
> You received this message because you are subscribed to the Google Groups "surfrdf" group.

> To view this discussion on the web visit https://groups.google.com/d/msg/surfrdf/-/m0KQd87cGk0J.

[Uldis Bojars]

Hi,

If there was not an already existing property, I'd call it
"direct_only" rather than "only_direct" (sounds more "english" to me).
But if the name is already in use then there's no need to change it.

Cheers,
Uldis


2012/4/27 cuu...@gmail.com <cuu...@gmail.com>: