refactor: move appstate logic to modules#5090
Conversation
952489e to
7309024
Compare
| import System.Directory (doesPathExist) | ||
|
|
||
| run :: AppState -> Weak ThreadId -> IO () | ||
| run :: AppState.AppState -> Weak ThreadId -> IO () |
There was a problem hiding this comment.
Did not review all of the PR (almost nothing in fact), but this caught my eye: This pattern of importing the type without prefix and then using all the functions from that module with prefix was introduced on purpose.
Do we really need to go to AppState.AppState? I don't think so.
The underlying idea is: use a prefix if it's not immediately clear what we're referring to without a prefix. There is no other AppState than AppState.AppState.
There was a problem hiding this comment.
Yeah, we don't need AppState.AppState. Now that I have changed to re-exporting AppState type, we don't need to touch this at all. 👍
wolfgangwalther
left a comment
There was a problem hiding this comment.
Personally, I think I consider Pool and Reload to be part of AppState - but I see how you don't want to put everything into one big AppState file.
I don't really like the idea of having a AppState.Types file and importing that everywhere else - I feel like this (the Types file) is an implementation detail of the (possibly split across files) AppState module.
How about:
- re-export the
AppStatetype fromAppState.hsand use that as before in all other files. - move
PoolandReloadintoAppState/and have these two import the "internal"Typesfile to avoid the cycle. - Still have
AppStatere-export whatever is needed elsewhere fromPool/Reload.
Have only spent like 5 minutes thinking about this, so maybe this doesn't work or maybe there is a better way.
7309024 to
7fd8f5e
Compare
| PostgREST.AppState.Pool | ||
| PostgREST.AppState.Reload | ||
| PostgREST.AppState.Types |
There was a problem hiding this comment.
I think it'd make sense to start adding the other-modules section for these. We'll control what to actually expose via PostgREST.AppState.
There was a problem hiding this comment.
Hm, agree. I'll open another issue to discuss not exposing internal modules.
EDIT: Opened #5105 to discuss that.
7fd8f5e to
7504b65
Compare
| -- | Run an action with a database connection. | ||
| usePool :: AppState -> SQL.Session a -> IO (Either SQL.UsageError a) | ||
| usePool appState@AppState{stateObserver=observer, ..} sess = do |
There was a problem hiding this comment.
The removal of usePool is in the 3rd commit, but should be in the 2nd commit where it is added in the other file.
Maybe make sure that each commit still builds (and passes postgrest-coverage as well) on its own?
There was a problem hiding this comment.
Ah, you're right. Will do.
I noticed we run weeder only on postgrest-coverage.
Lines 174 to 177 in f81dd29
It's easy to miss running postgrest-coverage, how about we run weeder as part of postgrest-lint instead? After all. it is a dead code detector so it should be part of lint script. WDYT?
There was a problem hiding this comment.
I think there was a reason for it. Does weeder need some of the build artifacts or so?
There was a problem hiding this comment.
The weeder readme says:
Weeder uses HIE files produced by GHC - these files can be thought of as source code that has been enhanced by GHC, adding full symbol resolution and type information.
There was a problem hiding this comment.
Weeder uses HIE files produced by GHC - these files can be thought of as source code that has been enhanced by GHC, adding full symbol resolution and type information.
Hm, so that means we can't include it in the postgrest-lint because that is supposed to only lint static source files without the need of any additional build artifacts? Makes sense.
I low-key still wish if we could have a separate postgrest- script for checking dead code, we could also include it in postgrest-check.
7504b65 to
97509a9
Compare
97509a9 to
538b53a
Compare
`AppState.hs` is imported by many modules. Some of those modules contain important functions that need to be imported back to `AppState.hs`, causing circular dependency problem. Signed-off-by: Taimoor Zaeem <taimoorzaeem@gmail.com>
Signed-off-by: Taimoor Zaeem <taimoorzaeem@gmail.com>
This commit moves, schema cache reload, config reload and listener reload logic to `Reload.hs` module. Signed-off-by: Taimoor Zaeem <taimoorzaeem@gmail.com>
538b53a to
09e7609
Compare
The problem occurs when solving #4894.
The way things were setup, we would have to move all the
Listener.hslogic toAppState.hsjust how allretryingSchemaCacheLoadlogic present inAppState.hseven though it doesn't belong to it. Without this, we run into circular dependency errors.This PR offers a module structure where all reloading logic is in
Reload.hsincluding schema cache reload, config reload and listener retrying (and later reloading it).Looking for feedback!
Notes