Updated database connection handling via pg_dump.

[vdragsic]

Connection arguments for pg_dump command are built from Rails.configuration.database_configuration` for current environment.

This reflects only on PostgresqlSchemaFromSqlAdapter.

[houndci-bot]

Line is too long. [108/80]

[jonsgreen]

+1

[NielsKSchjoedt]

From what I can see here, the problem with the excluded models is not really being fixed by leaving out those models when dumping/restoring. Now your FK constraints won't be prepended by the schema unless they point to a table in a different schema, than the one you dump from. Let me give an example:

Let's say you have an excluded model called user which resides in your default schema called wine_blog. You create your FK's so that they alway point to wine_blog.users. Then when you run Apartment::Database.create('food_blog'), it will do the following:

--
-- PostgreSQL database dump
--

--
-- Name: food_blog; Type: SCHEMA; Schema: -; Owner: -
--

CREATE SCHEMA food_blog;


--
-- Name: SCHEMA food_blog; Type: COMMENT; Schema: -; Owner: -
--

COMMENT ON SCHEMA  IS 'standard public schema';


SET search_path = food_blog;

(...)

--
-- Name: posts_user_id_fk; Type: FK CONSTRAINT; Schema: food_blog; Owner: -
--

ALTER TABLE ONLY posts
    ADD CONSTRAINT posts_user_id_fk FOREIGN KEY (users_id) REFERENCES users(id);

Now we have a problem, because when creating the new schema food_blog, it will suddenly reference food_blog.users as described. Where as what you really would want is something like:

ALTER TABLE ONLY posts
    ADD CONSTRAINT posts_user_id_fk FOREIGN KEY (users_id) REFERENCES wine_blog.users(id);

However that is never going to happen, because the wine_blog is your default_schema which is being used for dumping in the first place.

Now to get the right behavior, you would have to move all excluded models into a different schema (e.g. public), because then you would see public.users when dumping from your default wine_blog schema. The problem with this however would be, that migrations making changes to users would break, if they, besides the public schema, not also resides as "dummy"-tables in the _blog schemas.

To wrap up, the best idea is probably to leave the excluded models in all schemas, then make sure, that your FK's referring to excluded models, refer to the excluded model tables residing in the public persisted_schema, NOT in the default_schema.

Do you follow me?

[jenseng]

as a workaround for those waiting on this PR, pg_dump and friends support a variety of environment variables (e.g. PGUSER, PGPORT, etc.). when coupled with something like dotenv you can still keep all your db config in one place (e.g. database.yml could also pull from env vars)

[NielsKSchjoedt]

I made an alternative to this: #182