Generate db files during hanami new

[cllns]

Resolves #147.

A couple things.

1. I didn't add any DATABASE_URL to .env yet. I like the pattern of putting those into .env.development and .env.test. I know there was some discussion about an automatic translation from a development DATABASE_URL to a test one but not sure where we landed on that. When deploying to production, it's a feature that it won't deploy without DATABASE_URL set on the production server, so the development one isn't used accidentally.
2. I added some constants without private_constant so I can re-use them. I don't really like where they are now, any ideas of a better place to put them?
3. I removed passing along the rest of the kwargs to the context, due to some syntax errors on 3.0 and 3.1 since I broke up the method calls (I think). Not sure if this is a problem for extensibility?
4. I have the base repo inherit from Hanami::DB::Repo and added a FIXME for when rename that to Hanami::Repo
5. Do we want to add ROM transaction support in our base Operation? I think so.

[timriley]

This is looking great, thank you so much @cllns!

I've left a few small requests for you. Once these are done, we can get this in :)

[timriley]

This is a deviation from what I put in my proposal, but I wonder if this should go into app/db/repo.rb, since then it would go alongside all the other base classes, and since it's inheriting from a class in the Hanami::DB namespace, just like those other base classes in app/db/.

Seeing this in full now, I reckon it should. What do you think?

[cllns]

Yea, that makes sense to me. Should we also nest in a DB namespace like the other files in that folder? I feel like it should for consistency's sake. It could go either way since Repos are the bridge between app logic and persistence, so I don't feel strongly either way.

[timriley]

Thanks for the extra nudge about this question, @cllns!

Here's a decision for you: let's generate this into db/repo.rb.

With this change, we:

• Have the namespace of the class within the app echo the namespace of its superclass
• Put the app's repo base class alongside the struct base class, which feels sensible since its the job of repos to return struct instances in the first place
• Keep all the db-related support code together in one place
• Reinforce the location of db/ as the home for all db-support code, whether this is extra ROM components (like changesets or mappers), or arbitrary code that the user wants to mix in or use alongside the other db components
• Subtly reinforce that a user may choose to have other kinds of repo base classes, if they e.g. want to mix and match ROM-based repos with similarly-behaving repos of their own construction

Feels like you were happy to move in this direction, but I'm also happy to discuss further if you have any other thoughts or questions 😄

[cllns]

Addressed all your comments.

Should we also add default DATABASE_URL's to .env.development and .env.test?

[timriley]

Addressed all your comments.

Thanks @cllns, those changes look good!

Should we also add default DATABASE_URL's to .env.development and .env.test?

I reckon we should actually add it directly to a generated .env file!

Reasons:

• Per dotenv's docs, .env is safe to check in.
• Having to manage a database URL across two files is ungainly, and we actually have some some cool database URL handling in place now that will automatically ensure a _test suffix for the database name in test mode.

Together, this means a single .env with a single DATABASE_URL will be enough to cover all local development use cases! This feels a lot neater than having to generate two files and requiring new users to remember that the DATABASE_URL needs to be kept in sync across both.

Now, as the dotenv docs point out, if you check in a .env, then it's imperative you use the counterpart files that are not checked in (.env.development.local, etc.) to store any sensitive values.

To this end, I think we should:

1. Generate a .env with the DATABASE_URL in it
2. Put a comment at the top of .env making it clear that sensitive values should go in the other files
3. Change our .gitignore so that .env is no longer ignored, and add .env.local and .env.*.local in its place

How does this sound to you, @cllns?

Once this is done I reckon we should finally be at the point of a ready-to-go database-backed app after hanami new! 🎉

[timriley]

p.s. I re-ran the failing tests and they turned green (due to my making the latest dry-configurable gem release), so I think this should come good after the next push. It might need a rebase to get the latest GitHub actions workflow from the main branch though (with 3.0 removed).

[cllns]

Addressed all the comments and we're green again.

I also added include Dry::Operation::Extensions::ROM into the base Operation so users will be able to use transaction (unless they --skip-db)

[cllns]

Right now the app/db/repo.rb is generated as AppName::Repo, not AppName::DB::Repo. I feel like that's fine but just want to confirm that we're all OK with that, since it might be surprising. We could also alias it so it exists in both places, but that's a little strange too.

[timriley]

Thanks for thinking to include this! ❤️

This is definitely good to go in now. We want these operations to support DB transactions natively.

Seeing this inspired me to create an issue to help us eliminate this line of boilerplate before 2.2 final: hanami/hanami#1437

[timriley]

Thank you for your persistence here, @cllns!

After moving the base repo class to db/ (per my comment here), I think this is good to merge! 🎉

[cllns]

Sweet. All good now, with the base repo going into app/db/repo.rb as MyApp::DB::Repo

[timriley]

Thanks @cllns! I'm going to merge this now, since I want to start updating our getting started guide, and being able to generate a new app will help with that :)