-
Notifications
You must be signed in to change notification settings - Fork 370
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
feat(firestore): Add support for multiple named databases in Firestore #2209
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you! Added some comments
|
||
// @beta | ||
export function getFirestore(app: App, databaseId: string): Firestore; | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think if we combine the two methods the docs will be more readable.
export function getFirestore(app?: App, databaseId: string): Firestore;
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What I meant to say was to keep both as optional parameters so you don't need three method signatures. It also simplifies the docs.
export function getFirestore(app?: App, databaseId?: string): Firestore;
export function getFirestore(
appOrDatabaseId?: App | string,
optionalDatabaseId?: string
): Firestore {
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I still think calling getFirestore(null, 'myDB')
is worse than having overload getFirestore('myDB')
.
TypeScript doesn't expose the last signature, nor would I want to. The signature suggests someone could write code getFirestore('myDB', 'myDB')
which isn't allowed.
export function getFirestore(
appOrDatabaseId?: App | string,
optionalDatabaseId?: string
): Firestore
export { GrpcStatus } | ||
|
||
// @public | ||
export function initializeFirestore(app: App, settings?: FirestoreSettings): Firestore; | ||
|
||
// @beta | ||
export function initializeFirestore(app: App, settings: FirestoreSettings, databaseId: string): Firestore; | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it make more sense to include the databaseId
in FirestoreSettings
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TLDR; No, I I think this is a bad idea.
The admin SDK manages lifecycle of Firestore instances, such that subsequent requests will return the same instance. The app
and databaseId
form the key to this cache, and should really be held separate from settings in my opinion.
Other methods such as getFirestore
, do not take a settings object. Adding a settings object here would conflict with intent to have getFirestore
simply be a method to return an existing instance (if one exists).
initializeFirestore
cannot be called with different settings, since settings cannot be changed after Firestore instance has been started. The semantic difference that "some" settings such as database id
are allowed to change, will simply add confusion to interface. A simple rule that no settings are allowed to change can be maintained by excluding databaseId from settings.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense! Thank you
* service for the default app. | ||
* | ||
* `getFirestore()` can be called with no arguments to access the default |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please get these documentation changes reviewed by a tech writer before merging the PR. Thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks Mark!
RELEASE NOTE: Added support for multiple named databases. This feature is currently in public preview.