Skip to content

Datastore querying by multiple kinds supported in gcloud-node, but not by Datastore. #572

Description

@jgeewax

When running the following code:

var gcloud = require('gcloud');
var dataset = gcloud.datastore.dataset({
  projectId: 'my-project-id'
});

var query = dataset.createQuery(['Kind1', 'Kind2']);
dataset.runQuery(query, function(err, entities) {
  console.log(err);
  console.log(entities); // null
});

I get the following error returned: message: 'multiple kinds not supported'

According to https://cloud.google.com/datastore/docs/concepts/queries, Datastore allows querying over a single kind, not multiple.

Maybe we should remove the ability to construct a query with multiple kinds?

Activity

  1. added
    type: bugError or flaw in code with unintended results or allowing sub-optimal usage patterns.
    api: datastoreIssues related to the Datastore API.
    on May 9, 2015
  2. added this to the Datastore Stable milestone on May 9, 2015
  3. tmatsuo commented on May 9, 2015

    @tmatsuo
    Contributor
  4. jgeewax commented on May 9, 2015

    @jgeewax
    ContributorAuthor

    Yes, you can provide 0 or 1 Kinds, but not N.

  5. ryanseys commented on May 11, 2015

    @ryanseys
    Contributor

    Agreed, this should be addressed.

  6. jgeewax commented on May 11, 2015

    @jgeewax
    ContributorAuthor

    OK so the question then becomes, how do we sort this out? Some options:

    1. Change dataset.createQuery() to accept only one kind as a string
    2. Change dataset.createQuery() to still accept a list (or a string), but raise an exception if the list is more than one item long
    3. Change dataset.runQuery() to raise an exception if multiple kinds are there
    4. Change dataset.runQuery() to recognize the "multiple kinds not supported" error response and raise a more helpful error.

    @GoogleCloudPlatform/cloud-datastore : Is there any chance at all that Datastore will support queries of multiple kinds (not Kindless queries, but queries for Kind1, Kind2, ..., KindN) ?

    If the answer above is yes, we should probably go with the option that recognizes the error and raises it in a friendly way rather than trying to prevent people from doing this in client code.

  7. pcostell commented on May 12, 2015

    @pcostell
    Contributor

    Yes there is a plan to support queries on multiple kinds in the future, but I don't believe it is on our short-term roadmap.

  8. ryanseys commented on May 17, 2015

    @ryanseys
    Contributor

    Strange that the API is kinds that accepts an array of objects with { name: 'kind' }. Our code will remain the exact same but the documentation will change. They may provide an array of 1 kind and that will work still but it won't be documented as such.

  9. pcostell commented on May 17, 2015

    @pcostell
    Contributor

    Do you mean it's strange that it's an array of objects and not strings? If so, it's so we can support aliases (important if you want to select from the same kind multiple times).

  10. ryanseys commented on May 17, 2015

    @ryanseys
    Contributor

    I meant it's just strange that it accepts an array, and the property is kinds as opposed to kind (singular) which would more suggest that it only accepts one.

  11. Alfus commented on May 17, 2015

    @Alfus

    It is that way to potentially support queries like "SELECT * FROM Kind1 as
    A, Kind1 as B, Kind2 WHERE A.b = B.a AND Kind2.b = A.b" in the future.

    On Sun, May 17, 2015 at 10:51 AM Ryan Seys [email protected] wrote:

    I meant it's just strange that it accepts an array, and the property is
    kinds as opposed to kind (singular) which would more suggest that it only
    accepts one.

    —
    Reply to this email directly or view it on GitHub
    #572 (comment)
    .

  12. 14 remaining items

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

api: datastoreIssues related to the Datastore API.type: bugError or flaw in code with unintended results or allowing sub-optimal usage patterns.

Type

No type

Projects

No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions