Skip to content

Ensure persistence started #1043

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

Merged
merged 4 commits into from
Jul 25, 2018
Merged

Conversation

gsoltis
Copy link

@gsoltis gsoltis commented Jul 24, 2018

This mostly fixes up the spec tests so that we can assert that LocalStore always gets an already-started Persistence instance.

@@ -96,7 +96,10 @@ export class IndexedDbPersistence implements Persistence {
static MAIN_DATABASE = 'main';

private simpleDb: SimpleDb;
private started: boolean;
private hasStarted: boolean;
Copy link
Contributor

Choose a reason for hiding this comment

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

The general convention for exposing properties that are only readonly via the public API is to use an underscore. So this would be:

private _started: boolean;
get started(): boolean {
    return this._started;
}

Please also move the getter to where the other getters/methods are defined. You could also initialize _started with 'false'.

Copy link
Author

Choose a reason for hiding this comment

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

Done.

@@ -140,12 +142,15 @@ export class IndexedDbPersistence implements Persistence {
.then(() => {
this.scheduleOwnerLeaseRefreshes();
this.attachWindowUnloadHook();
})
.then(() => {
this.hasStarted = true;
Copy link
Contributor

Choose a reason for hiding this comment

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

This can be part of the previous then block.

But that being said, I don't this will work one I merge my multi-tab PR. In the new scheduleOwnerLeaseRefreshes I am using started to determine whether I should issue callbacks. We essentially need three states: not-started, starting, started. And since nothing else should be happening while we call .start(), it should be safe to keep flipping the started bit in the beginning?

Copy link
Author

Choose a reason for hiding this comment

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

As discussed, leaving this at the end in its own .then() call.

@@ -163,6 +163,10 @@ export class LocalStore {
*/
private garbageCollector: GarbageCollector
) {
assert(
persistence.started,
'Local Store passed an unstarted persistence implementation'
Copy link
Contributor

Choose a reason for hiding this comment

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

The LocalStore is the receiver here, which doesn't quite come across in this message (maybe it is just missing a was as in was passed )

Copy link
Author

Choose a reason for hiding this comment

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

Done.

@@ -45,18 +45,21 @@ export class MemoryPersistence implements Persistence {
private remoteDocumentCache = new MemoryRemoteDocumentCache();
private queryCache = new MemoryQueryCache();

private started = false;
private hasStarted = false;
Copy link
Contributor

Choose a reason for hiding this comment

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

Same comment about naming.

Copy link
Author

Choose a reason for hiding this comment

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

Done.

@@ -75,6 +75,11 @@ export interface Persistence {
*/
start(): Promise<void>;

/**
Copy link
Contributor

Choose a reason for hiding this comment

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

Nit: I would move the property declarations to the top.

Copy link
Author

Choose a reason for hiding this comment

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

Done.

this.persistence = new Promise(resolve => {
const p = this.getPersistence(this.serializer);
p.start().then(() => resolve(p));
});
Copy link
Contributor

Choose a reason for hiding this comment

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

Hmm, this is somewhat strange. Can we not start the persistence layer in the renamed start()? We can check there whether it is already started using your new nifty API.

Copy link
Author

Choose a reason for hiding this comment

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

We technically could, but doRestart() calls start(), and doRestart() intentionally does not want to start the persistence layer. As such, I think it makes more sense to keep the call to persistence.start() in the one place where we know we want to start it, rather than gate it with an if (!persistence.started) await persistence.start(), which then means you have to know why it would or wouldn't already be started.

async shutdown(): Promise<void> {
await this.remoteStore.shutdown();
await this.persistence.shutdown(/* deleteData= */ true);
await (await this.persistence).shutdown(/* deleteData= */ true);
Copy link
Contributor

Choose a reason for hiding this comment

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

Please try to find a way to make this a non-Promise again.

Copy link
Author

Choose a reason for hiding this comment

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

Restructured to have an init and a start.

@gsoltis gsoltis assigned schmidt-sebastian and unassigned gsoltis Jul 25, 2018
Copy link
Contributor

@schmidt-sebastian schmidt-sebastian left a comment

Choose a reason for hiding this comment

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

Thanks for the changes. LGTM.

@gsoltis gsoltis merged commit fc2e967 into master Jul 25, 2018
@gsoltis gsoltis deleted the gsoltis/ensure_persistence_started branch July 25, 2018 22:03
@firebase firebase locked and limited conversation to collaborators Oct 18, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants