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)
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:
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 install
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).
My questions
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?
Hmpf. yarn rw dev should generate the database and the migrations should be applied. Can you verify that you have migrations in your ./api/db/migrations/ folder?
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)
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 useBaseQuery.js:31
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 react-dom.development.js:11327
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)
at useBaseQuery.js:17
index.js:1 The above error occurred in the <Query> component:
at Query (http://localhost:8910/static/js/app.chunk.js:12486:3)
at http://localhost:8910/static/js/app.chunk.js:12567:7
at main
at div
at UserExamplesLayout (http://localhost:8910/static/js/3.chunk.js:478:12)
at UserExamplesPage
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 Router
at Routes
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)
at App
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.
@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
(I am not serious here 
