Improve minor config friction when scaffolding prisma

[cyremur]

Problem Description

As a developer trying out the stack for the first time, I ran into some friction when switching from local db.sqlite to a hosted postgres DB.

npx prisma db push
Environment variables loaded from .env
Prisma schema loaded from prisma\schema.prisma
Error code: P1012
error: Error validating datasource `db`: the URL must start with the protocol `file:`.
  -->  schema.prisma:11
   | 
10 |     // url      = "file:./db.sqlite"
11 |     url      = env("DATABASE_URL")

In schema.prisma, I had to adjust db.provider from sqlite to postgresql.

Additionally, the .gitignore file didn't include the db.sqlite file created on intended first local setup.

Describe the solution you'd like

1. Include DATABASE_PROVIDER setting in the .env-example and commented out in schema.prisma to make it obvious that it needs to be set as well when using a DATABASE_URL.
2. Use partial, feature dependent templates for .env-example and .gitignore / _gitignore that are concatted into the full file during scaffolding based on selected features (i.e. concat base/_gitignore and prisma/_gitignore).

Happy to work on this if considered beneficial.

[cyremur]

Just found out that apparently using .env for db.provider is not supported.

Maybe just add a comment instead? Or should this be obvious to people in general?
// url = env("DATABASE_URL") // remember to adjust provider as well

[juliusmarminge]

Include DATABASE_PROVIDER setting in the .env-example and commented out in schema.prisma to make it obvious that it needs to be set as well when using a DATABASE_URL

I dont think the provider is a environment variable so putting it there would make no sense to me.

Maybe just add a comment instead? Or should this be obvious to people in general?
// url = env("DATABASE_URL") // remember to adjust provider as well

I think if you are switching to another database solution you will have to make changes no matter what, like if you are moving to Planetscale you have to enable referential-integrity and stuff. Another thing you have to keep track of yourself is if using Next-Auth.js you cannot use sqlite because it is not supported. These types of stuff are things that, in my opinion, the user have to change themselves.

[c-ehrlich]

I agree that the provider should absolutely not be an environment variable. Prisma is not designed to work like that.

Overall I believe that doing as little custom stuff as possible with Prisma is the way to go - the goal should be that people who have used Prisma before in some other context will not run into any surprises when using ct3a.

[juliusmarminge]

the goal should be that people who have used Prisma before in some other context will not run into any surprises when using ct3a

Absolutely, ct3a doesnt mean you dont have to do anything yourself. You should know about the tech and if you dont, refer to the respective docs. (The docs for prisma schema is even listed at the top of the file)

create-t3-app/template/addons/prisma/schema.prisma

Lines 1 to 2 in e7c5059

	// This is your Prisma schema file,
	// learn more about it in the docs: https://pris.ly/d/prisma-schema

Closing this for now.

[cyremur]

Hi, for what it's worth this ticket was mostly born from perfectionism and trying to utilize my being new to the stack to make on boarding as smooth as possible. I fully agree that this should not pose an actual issue for developer.

Happy to point out the gitignore change and I am looking forward to keep developing with this stack. Experience so far has been amazing. Maybe I can contribute something more substantial further down the line.