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

feat(firestore): Add support for multiple named databases in Firestore #2209

Merged
merged 2 commits into from
Jun 14, 2023

Conversation

tom-andersen
Copy link
Contributor

@tom-andersen tom-andersen commented Jun 9, 2023

RELEASE NOTE: Added support for multiple named databases. This feature is currently in public preview.

Copy link
Member

@lahirumaramba lahirumaramba left a 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;

Copy link
Member

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;

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think inviting customers to pass null as a parameter is a bad idea.

The problem is in doc generation that doesn't include parameters in signature:

image

Copy link
Member

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 {

Copy link
Contributor Author

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;

Copy link
Member

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?

Copy link
Contributor Author

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.

Copy link
Member

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
Copy link
Member

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!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks Mark!

@tom-andersen tom-andersen merged commit 8c643da into master Jun 14, 2023
@lahirumaramba lahirumaramba changed the title Expose MultiDB within Firestore feat(firestore): Add support for multiple named databases in Firestore Jun 14, 2023
@lahirumaramba lahirumaramba deleted the tomandersen/exposeMultiDb branch June 14, 2023 15:39
lahirumaramba added a commit that referenced this pull request Jul 12, 2023
lahirumaramba added a commit that referenced this pull request Jul 12, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants