Repository navigation
Why is datastore initialized differently than the other libraries? #593
Description
Activity
- addedapi: datastoreIssues related to the Datastore API.Issues related to the Datastore API.type: questionRequest for information or clarification. Not an issue.Request for information or clarification. Not an issue.
on May 12, 2015 I would really like to do the last one. @rakyll said to anticipate more things added to Datastore, which was why we couldn't do it.
I'm down for:
var gcloud = require('gcloud')(options); var datastore = gcloud.datastore(newOptions); var dataset = datastore.dataset('name of the dataset' /* optional */); var key = datastore.key('Company'); datastore.save(key, { data: { hello: 'world' } }, callback);
The reason we can't kill data set is that we are in the process of adding the ability to have multiple datasets (we'll probably call them databases) per project, so
datastore.save()is a misleading concept...But I still think we need to allow you to configure stuff at the datastore level... ? right?
Oh, as far as I understand right now we have no concept of a name of a dataset, right? In that case I like my first new proposal where it will just take no options for the time being until this multi-dataset functionality rolls around. This would be a breaking change.
datastore.dataset()should always still work, and default to the ID of the project. In the future, we need a way of passing in a name of a dataset (datastore.dataset('name')).Don't think this should be a breaking change, right?
It would be breaking because gcloud.datastore will now be a function that needs to be called with options. datastore.dataset will no longer accept these options. And it doesn't make sense to have it in both places.
Gotcha - we couldn't make it work with and without the parens? (
gcloud.datastore==gcloud.datastore()) ?Maybe but if we're in the business of breaking things with the moving of options from dataset to datastore then we should just break it. Also this is much easier to do pre-1.0
Just want to make sure this is correct:
// uses dataset-id-1: var gcloud = require('gcloud')({ projectId: 'dataset-id-1' }); gcloud.datastore.dataset(); // uses dataset-id-2: var gcloud = require('gcloud')({ projectId: 'dataset-id-1' }); var datastore = gcloud.datastore({ projectId: 'dataset-id-2' }); datastore.dataset(); // uses dataset-id-3: var gcloud = require('gcloud')({ projectId: 'dataset-id-1' }); var datastore = gcloud.datastore({ projectId: 'dataset-id-2' }); datastore.dataset('dataset-id-3'); // the projectId given above is useless.
@callmehiphop does this change how you would approach your PR (#845) at all?
I don't believe so, I think it would simplify the api object creation though.
This is going to be not-a-thing when datastore v1beta3 is released (see #897). The
datasetconcept is gone and there is only a "datastore" per project.16 remaining items
- added a commit that references this issue
on Feb 3, 2026 - added 2 commits that reference this issue
on Feb 5, 2026 - added 6 commits that reference this issue
on Feb 23, 2026 - added a commit that references this issue
on Feb 26, 2026
See here for what I'm talking about. Seems that once
gcloudis initialized, datastore cannot be initialized with different options. I think this is because we delegated it to thedatasetobject instead but that just is kinda messy. Would it be worth it to change this to be consistent with the other APIs?Current way:
Proposed way:
ADDITIONAL CRAZY IDEA: What if we just eliminated the
datasetaltogether? Something like:Anything preventing us from doing this?