Get app to buildable state about maybe HOT 14 CLOSED

When running yarn run dev:services postgres is getting setup via the docker-compose.yml file. Specifically:

postgres:
        container_name: postgres
        profiles: [services]
        image: timescale/timescaledb:latest-pg14
        ports:
            - 5432:5432
        environment:
            POSTGRES_USER: maybe
            POSTGRES_PASSWORD: maybe
            POSTGRES_DB: maybe_local
        volumes:
            - postgres_data:/var/lib/postgresql/data
         

I just used the .env.example which has the database url set as NX_DATABASE_URL=postgresql://maybe:maybe@localhost:5432/maybe_local

from maybe.

I posted in the Discord regarding this but I was able to get it up and running without issue. After yarn install you need a yarn run dev:services to get the Docker pieces up and running w/ docker-compose.

from maybe.

I'm on the step where I have all running... but I have error with 'replace_this' on the page. I don't know what put in this NEXT_PUBLIC_AUTH0_[XXX] env variables from apps/client/env.ts file.

from maybe.

I was able to get this to build fine too using either docker-compose --profile services up -d or more succinctly yarn run dev:services I submitted a PR to add these to the readme as well as run docker in detached mode.

from maybe.

@ductilestudios Is that the only change made? Basically wondering if your PR alone addresses the build issues such that a new user can go from pulling down the repo for the first time to "up and running" with no errors.

from maybe.

I wiped my install and redid with those added steps and yes I believe that's all that's needed to get up and running. I'll caveat that the dev server starts but the app is not accessible, as @damian0x mentioned, but I'm guessing that's because of not having Auth0 setup. Figure that is the next step under the Auth issue.

from maybe.

Sounds good. Will get that merged and if any other issues come up, we can debug separately from this.

from maybe.

This is probably ignorance on my part with Docker, but if postgres is being run inside docker, what should the local user/pass be for accessing the database?

I guess specifically what do you have NX_DATABASE_URL set up?

$ prisma migrate dev
Environment variables loaded from .env
Prisma schema loaded from prisma/schema.prisma
Datasource "db": PostgreSQL database "maybe_local", schema "public" at "localhost:5432"

Error: P1010: User `maybe` was denied access on the database `maybe_local.public`
error Command failed with exit code 1.

from maybe.

Oooo, you know what...I've already got Postgres installed on my machine running on port 5432...so that's what it's trying to connect to.

...I need to think through how to solve that.

Does it make sense to change the default port that Docker is installing to since 5432 is the defacto for Postgres?

from maybe.

I'm 79.2% sure this is my ignorance on how Docker works. It seems Docker is actually trying to use my already-installed Postgres installation.

But if I pass in those credentials to NX_DATABASE_URL, I get the whole "timescale" error:

prisma migrate dev
Environment variables loaded from .env
Prisma schema loaded from prisma/schema.prisma
Datasource "db": PostgreSQL database "maybe_local", schema "public" at "localhost:5432"

PostgreSQL database maybe_local created at localhost:5432

Error: P3006

Migration `20211203180216_security_pricing` failed to apply cleanly to the shadow database. 
Error:
ERROR: extension "timescaledb" is not available
DETAIL: Could not open extension control file "/Applications/Postgres.app/Contents/Versions/15/share/postgresql/extension/timescaledb.control": No such file or directory.
HINT: The extension must first be installed on the system where PostgreSQL is running.
   0: sql_schema_connector::validate_migrations
           with namespaces=None
             at schema-engine/connectors/sql-schema-connector/src/lib.rs:324
   1: schema_core::state::DevDiagnostic
             at schema-engine/core/src/state.rs:267

error Command failed with exit code 1.

from maybe.

I'm going to send a PR to move to port 5433, let's see if that fixes it for you.

In my experience using non standard ports is a mixed bag of whether it simplifies or complicates on any given day, but in this case it should be a way for you to run a clean copy.

from maybe.

I'll also note that mine initially failed to apply cleanly on that same migration, but it prompted me to reset from scratch, which worked fine

The migration `20211203180216_security_pricing` failed.
✔ We need to reset the "public" schema at "localhost:5432"
Do you want to continue? All data will be lost. … yes

from maybe.

If you want to debug your current install, my first step would be to do a docker container ls and see what image your container is running off.

From the docker-compose.yml I get:

CONTAINER ID   IMAGE                               COMMAND                  CREATED             STATUS          PORTS                    NAMES
ff49a749c7f4   timescale/timescaledb:latest-pg14   "docker-entrypoint.s…"   14 minutes ago      Up 14 minutes   0.0.0.0:5433->5432/tcp   postgres
558aa4c046d6   redis:6.2-alpine                    "docker-entrypoint.s…"   About an hour ago   Up 14 minutes   0.0.0.0:6379->6379/tcp   redis

from maybe.

Changing the default port to 5433 did the trick for me.

Going to merge that and we'll see if that becomes problematic for anyone in the future.

from maybe.