If a question allows chasing down the ratholes - that is what will happen. For example: instead of asking a very specific question, I wrote the new topic under the title defined as a statement - not a question (see below)
Instead, I should have asked:
How to restore RW app database
Realizing the question is very incomplete, I will follow up with the description of the process that led me to this new question.
While testing the accuracy and completeness of the Tutorial I, I would add the verified sections to my repository on Github, planning to create my own copy of the tutorial code, which I plan to use for my slowly coming document on Windows-specific aspects of RedwoodJS applications development.
Halfway through this exercise, I decided to clone my Tutorial app and verify that it behaves correctly. To my surprise, I saw this:
Note that the original app being built step by step works flawlessly
Look at the
dev.db database (original and clone) tells a lot:
While running the Tutorial step by step, editing code, and running generators, the database of the original application was “built” by running data migrations.
In order to run the cloned Tutorial app, I just did:
yarn rw dev
where I was assuming that
yarn rw dev would invoke the needed data migration (it’s is just one in this case).
- Is the above issue a bug or a feature?
- If it is a feature, could a paragraph’s worth of description and instructions what needs to be done to make the clone “complete” be added to the tutorial ?
- Am I the only one that got himself in this trouble?
yarn rw dev should generate the database and the migrations should be applied. Can you verify that you have migrations in your
Finally, someone responds (I am not serious here @peterp, I am just showing my joy that it’s you of all people who responded). Since RWJS documentation is not shy pointing out how smart and developer-friendly the framework is, I was pretty sure that I am dealing with a bug. The following screenshot depicts the migration “situation” for the app described in Docs - Quick Start : RedwoodJS Docs (as rendered by VSCode)
Note that this app was not at this point persisted at GitHub, so I will call it
I also “pushed” the
original to GitHub, made its clone in a different folder, and then run the following commands"
yarn rw dev
The VSCode shows the same view as rendered for the
Invoking this app via the browser using the URL
http://localhost:8910/user-examples I got the following response:
[HMR] Waiting for update signal from WDS...
scheduler.development.js:298 [Deprecation] SharedArrayBuffer will require cross-origin isolation as of M91, around May 2021. See https://developer.chrome.com/blog/enabling-shared-array-buffer/ for more details.
(anonymous) @ scheduler.development.js:298
invariant.esm.js:35 Download the Apollo DevTools for a better development experience: https://chrome.google.com/webstore/detail/apollo-client-developer-t/jdkknkkbebbapilgoeccciglkfbmbnfm
index.js:1 Warning: Did not expect server HTML to contain the text node "
" in <div>.
console.<computed> @ index.js:1
withCellHOC.js:123 Uncaught Error:
Invalid `prisma.userExample.findMany()` invocation:
The table `main.UserExample` does not exist in the current database.
at new ApolloError (index.js:26)
at QueryData._this.getQueryResult (QueryData.js:31)
at QueryData.push.../node_modules/@apollo/client/react/data/QueryData.js.QueryData.getExecuteResult (QueryData.js:149)
at QueryData.push.../node_modules/@apollo/client/react/data/QueryData.js.QueryData.execute (QueryData.js:98)
at useDeepMemo (useDeepMemo.js:6)
at useBaseQuery (useBaseQuery.js:31)
at Object.useQuery (useQuery.js:3)
at useQuery (GraphQLHooksProvider.js:52)
at Query (withCellHOC.js:28)
at renderWithHooks (react-dom.development.js:14985)
at updateFunctionComponent (react-dom.development.js:17356)
at beginWork (react-dom.development.js:19063)
at beginWork$1 (react-dom.development.js:23940)
at performUnitOfWork (react-dom.development.js:22776)
at workLoopSync (react-dom.development.js:22707)
at renderRootSync (react-dom.development.js:22670)
at performSyncWorkOnRoot (react-dom.development.js:22293)
at unstable_runWithPriority (scheduler.development.js:646)
at runWithPriority$1 (react-dom.development.js:11276)
at flushSyncCallbackQueueImpl (react-dom.development.js:11322)
at flushSyncCallbackQueue (react-dom.development.js:11309)
at scheduleUpdateOnFiber (react-dom.development.js:21893)
at dispatchAction (react-dom.development.js:16139)
index.js:1 The above error occurred in the <Query> component:
at Query (http://localhost:8910/static/js/app.chunk.js:12486:3)
at UserExamplesLayout (http://localhost:8910/static/js/3.chunk.js:478:12)
at PageLoader (http://localhost:8910/static/js/app.chunk.js:11315:5)
at Loaders (http://localhost:8910/static/js/app.chunk.js:11597:3)
at RouterImpl (http://localhost:8910/static/js/app.chunk.js:11613:3)
at LocationProvider (http://localhost:8910/static/js/app.chunk.js:11133:5)
at Location (http://localhost:8910/static/js/app.chunk.js:11189:3)
at GraphQLHooksProvider (http://localhost:8910/static/js/app.chunk.js:12431:3)
at ApolloProvider (http://localhost:8910/static/js/app.chunk.js:6410:21)
at ApolloProviderWithFetchConfig (http://localhost:8910/static/js/app.chunk.js:12153:3)
at FetchConfigProvider (http://localhost:8910/static/js/app.chunk.js:12342:3)
at RedwoodApolloProvider (http://localhost:8910/static/js/app.chunk.js:12209:3)
at FatalErrorBoundary (http://localhost:8910/static/js/app.chunk.js:12275:5)
React will try to recreate this component tree from scratch using the error boundary you provided, FatalErrorBoundary.
console.<computed> @ index.js:1
index.js?http:/localhost:8910:48 [WDS] Hot Module Replacement enabled.
index.js?http:/localhost:8910:52 [WDS] Live Reloading enabled.
Note that the original application behaves correctly.
In order to verify my report, the app used in this problem report is here.
Lastly, the view of the dev.db after running the command
yarn rw dev
@peterp , @thedavid - a quick update for you: the problem described in this topic remains in the v.0.28 (my implicit understanding is that Peter ceased looking into this issue, being busy with pushing the v0.28.0 out the door. Please correct me if my impression that this is a showstopper bug is incorrect