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

Expose databaseId and projectId on Firestore class #1936

Closed
IchordeDionysos opened this issue Oct 28, 2023 · 1 comment · Fixed by #1937, #1963 or #1996
Closed

Expose databaseId and projectId on Firestore class #1936

IchordeDionysos opened this issue Oct 28, 2023 · 1 comment · Fixed by #1937, #1963 or #1996
Assignees
Labels
api: firestore Issues related to the googleapis/nodejs-firestore API. priority: p3 Desirable enhancement or fix. May not be included in next release. type: feature request ‘Nice-to-have’ improvement, new feature or different behavior or design.

Comments

@IchordeDionysos
Copy link
Contributor

Given the introducing of multiple databases it becomes more and more often that you want to know from where a Reference or snapshot was created for.

Right now there is no way to go from a DocumentReference or a DocumentSnapshot to the database or the project.

It should simply be possible to do the following:

reference.firestore.databaseId
reference.firestore.projectId

Those getters already exist but they are marked a private/internal making accessing them in Typescript unavailable.

Right now you need to do some fishy stuff accessing internal variables, silencing Typescript errors (using as any) or other unofficial, undocumented things.

Given those things are not officially supported and APIs may change without proper breaking changes this makes depending on those workarounds, not a solution.

@IchordeDionysos IchordeDionysos added priority: p3 Desirable enhancement or fix. May not be included in next release. type: feature request ‘Nice-to-have’ improvement, new feature or different behavior or design. labels Oct 28, 2023
@product-auto-label product-auto-label bot added the api: firestore Issues related to the googleapis/nodejs-firestore API. label Oct 28, 2023
@IchordeDionysos IchordeDionysos changed the title Expose databaseId on Firestore class feat: Expose databaseId and projectId on Firestore class Oct 28, 2023
@IchordeDionysos IchordeDionysos changed the title feat: Expose databaseId and projectId on Firestore class Expose databaseId and projectId on Firestore class Oct 28, 2023
@IchordeDionysos
Copy link
Contributor Author

@tom-andersen with Multi-DB support, I think this is essential to effectively work with it.
And it should be a small easy change to get approved in your internal API change (I hope at least 🥹)

I checked the other SDKs (Android, iOS) that allow to retrieve the settings again (which the NodeJS SDK does not), so it could be an option to do:

reference.firestore.settings.databaseId
reference.firestore.settings.projectId

There would be naming conflict though between the settings getter and the existing setter.

/cc @wu-hui

@tom-andersen tom-andersen self-assigned this Oct 30, 2023
gcf-merge-on-green bot pushed a commit that referenced this issue Dec 21, 2023
Thank you for opening a Pull Request! Before submitting your PR, there are a few things you can do to make sure it goes smoothly:
- [x] Make sure to open an issue as a [bug/issue](https://togithub.com/googleapis/nodejs-firestore/issues/new/choose) before writing your code!  That way we can discuss the change, evaluate designs, and agree on the general idea
- [ ] Ensure the tests and linter pass
- [ ] Code coverage does not decrease (if any source code was changed)
- [ ] Appropriate docs were updated (if necessary)

Fixes #1936
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api: firestore Issues related to the googleapis/nodejs-firestore API. priority: p3 Desirable enhancement or fix. May not be included in next release. type: feature request ‘Nice-to-have’ improvement, new feature or different behavior or design.
Projects
None yet
2 participants