Skip to content
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

datacube.select() always returns all dimensions #25

Open
lucguillemot opened this issue Sep 16, 2019 · 3 comments
Open

datacube.select() always returns all dimensions #25

lucguillemot opened this issue Sep 16, 2019 · 3 comments

Comments

@lucguillemot
Copy link

When running a query like this

const query = datacube
  .query()
  .select({
    measurement: measures[0],
    ageGroup: dimensions[3],
  })

I would expect the returned data to only contain the named dimension ageGroup and the associated measurement.

Actually, the returned data does contain the named dimension and the measure, but also includes all the other dimensions with a generated name tmpVar1, tmpVar2, etc. Is it the desired behavior? I'm using v.0.0.10.

Thanks!

@ktk
Copy link
Member

ktk commented Sep 17, 2019

This is IMO intended behavior, I would expect that I always get all dimensions back as from a RDF Data Cube vocabulary perspective, they are all mandatory.

Could you explain on an example on why you would expect to get just the referenced dimension back? Maybe we are missing something here but I can't follow so far.

@jstcki
Copy link
Contributor

jstcki commented Sep 17, 2019

What's the purpose of explicitly using .select then?

One example that doesn't work if dimensions are "auto-selected" would be to get all DISTINCT values of one dimension:

query.select({ageGroup: ageGroupDim}).distinct()

… currently this returns too many values because DISTINCT is applied to all variable combinations.

Or: If we filter by one dimension, we don't necessarily need to .select it anymore (we may want to but would like to stay in control). By selecting less fields, we also expect to fetch less data, which is more efficient.

In general it's just unexpected and confusing that using .select doesn't really align with what's SELECTed.

...

Maybe if this library is intended to deviate from SPARQL more, then actually .select should be removed altogethe?

@vhf
Copy link
Contributor

vhf commented Sep 17, 2019

Honestly I don't like this approach either, automagically adding things to the select doesn't feel right API-wise.

@vhf vhf added the discussion label Oct 21, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants