-
Notifications
You must be signed in to change notification settings - Fork 17
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
Introduction of a SuperThis #183
Conversation
This is a pretty wide change and I would benefit from some additional context to properly review. What is a SuperThis? Is this a common construct in the js/ts world for dependency injection purposes? |
The superthis is the finalization of the passthrough of the logger --- but due to the endless loop fix I ran into the situation that the "async" process doesn't enough about the "runtime" and I'm not able to pass the runtime down. |
At least we agree that it is ugly. |
OK, so since my ability to review this in the abstract is somewhat limited. I instead set out to test this branch with the gateway I've been working on. It took some effort to even get things running as well as before, but it was useful in at least letting me appreciate these changes in practice (most of the questions I had could be answered by the PR itself). Also, I've heavily modified the PK logic to function almost identically to the file gateway now (just writes to the party room instead of disk). Eventually we'll make use of the websocket again for the realtime updates. As I said, my test still doesn't work. It doesn't hang, Bob just never sees the data that Alice wrote (syncing to same PK). One question I have, in the test, I try to force the update with (shown are my previous and current way of doing it)
Is that correct? |
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.
This is a first-pass review, with some notes intended to help @necrodome join the conversation.
- SuperThis is somewhat equivalent to a context object, in Go context.Context is a reasonable analog
- Existing 'SuperThis' name is problematic, alternate under consideration "fpContext"
- As a coding convention, we would standarize on this as the first argument when wiring up the codebase
- Previously we passed a logger instance to most places, and now the logger is inside sthis, so many of the changes in this PR are of the form
s/logger/sthis/
- I can report that this branch basically works (last tested by me before all commits were present)
My open questions/concerns
- It would be great to remove the extraneous stuff from this PR, specifically fragmentation stuff is unrelated
- What is the long-term plan for RemoteMetaStore (lots of refs just commented out)
- Is there any cleaner/standard way of doing this is JS/TS world? Are there are libraries that do something similar that we can point to?
- I would like to clarify the life-cycle of SuperThis. In Go in particular, you are advised to not store context objects inside structs, and I believe the context objects are themselves immutable (modifying it creates a new instance). This detail will become important if we are using it for things like instrumentation/tracing which may contain state (ie, current active span). I ask this because I see mostly pass sthis during initialization and stash it inside the struct. This may also relate to the clone() method, would like it's usage clarified.
- I interpretted jchris's guidance to favor moving quickly at the moment, so I also want to be cognizant of overdoing this review
Alright I thought maybe I could fix up some minor things and get it usable again, but seems to be more significant than I realized. |
For the time being I'm basing future work on |
src/runtime/gateways/file/utils.ts
Outdated
} | ||
return SysContainer.join(basePath); |
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.
this looks like the action
for integration work with connect repo I am using 22d9221 for now |
is this part of #185 now? I think we should merge both |
chore: replace sys -> pathOps chore: added CarTransactionOpts chore: remove uuid chore: integrated registerKeyBagProviderFactory chore: enable stack on log chore: introduce memorygateway
); | ||
} | ||
|
||
export class DatabaseShell<DT extends DocTypes = NonNullable<unknown>> implements Database<DT> { |
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 wanna understand what motivates this layer
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.
close need to be refcounted
if you open multiple times the same database like:
db1 = fireproof("test")
db2 = fireproof("test")
db3 = fireproof("test")
db4 = fireproof("test")
db1.close()
db2.close()
db4.close()
db3.close() // realclose is done. w
then close should do nothing until the last instance is closed.
We had some test which tested for that behaviour.
@@ -0,0 +1 @@ | |||
export const MEMORY_VERSION = "v0.19-memory"; |
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.
is this supposed to be checked in?
@@ -84,7 +97,7 @@ describe("public API", function () { | |||
}); | |||
it("should be a database instance", function () { | |||
expect(db).toBeTruthy(); | |||
expect(db instanceof Database).toBeTruthy(); | |||
expect(isDatabase(db)).toBeTruthy(); |
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.
not sure our downstream users can be expected not to use instanceof
maybe we should have both assertions? I'm not sure what isDatabase would be used for outside of this, so maybe we remove the test?
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!
This should change no behavior but finally bring a stable dependency injection platform to the codebase.