Fixtures, Postgres & Constraints

Anyone have any tips for handling postgres constraints when using
fixtures to load the database, other than to sort out the proper
insertion orders or leaving the constraints out? I’d prefer not to do
the former since I’d rather use my app to generate my fixture data
(using a dump_fixtures task) and I’d prefer not to do the latter
because leaving out constraints till the end makes it easy (for me) to
forget one or two. The use case here is that I’m trying to synch my
entire app (including database schema and data) between two of my
development machines (laptop and desktop) using only subversion and
rake. Migrations aren’t really the answer because this isn’t about
promotion, just rapid synching from a single script I can run on
either machine.


Jeremy H.

On Mon, 2006-03-27 at 18:27 -0500, Jeremy H. wrote:

promotion, just rapid synching from a single script I can run on
either machine.


true but working through the migrations got me to figure out the
drop/add order and to use raw sql code to add to add the foreign key
constraints back in so I am expecting that will give me a leg up on
setting up testing (I’m hoping it will). Evidently migrations handles
creating all of the primary key constraints for me so I stopped trying
to do that myself.

Craig

On Mon, 2006-03-27 at 18:27 -0500, Jeremy H. wrote:

promotion, just rapid synching from a single script I can run on
either machine.


by the way, I don’t see a ‘dump fixtures’ option in ‘rake --tasks’ - is
that a gem or a plugin?

Craig

On Mon, 2006-03-27 at 18:58 -0500, Jeremy H. wrote:

I’m writing migrations for promotion to stage and production but I
really this to be dead simple and I don’t want to mess with migrations
for every interim change; I’d rather get my app how I want it and
write migrations to handle the diffs.

The dump fixtures is just some simple code I found, but pretty useful.

http://comments.gmane.org/gmane.comp.lang.ruby.rails/28315


any clue on where the table_names definition would logically go since
that is erb and it doesn’t seem logical to go into dump_fixtures.rake

Craig

Yes I had the same question - it does go in the dump_fixtures.rake, I
put it near the top with the other assignments.

On 3/27/06, Craig W. [email protected] wrote:


insertion orders or leaving the constraints out? I’d prefer not to do
by the way, I don’t see a ‘dump fixtures’ option in ‘rake --tasks’ - is

[email protected]
http://lists.rubyonrails.org/mailman/listinfo/rails


Jeremy H.

I’m writing migrations for promotion to stage and production but I
really this to be dead simple and I don’t want to mess with migrations
for every interim change; I’d rather get my app how I want it and
write migrations to handle the diffs.

The dump fixtures is just some simple code I found, but pretty useful.

http://comments.gmane.org/gmane.comp.lang.ruby.rails/28315

On 3/27/06, Craig W. [email protected] wrote:

rake. Migrations aren’t really the answer because this isn’t about
[email protected]
http://lists.rubyonrails.org/mailman/listinfo/rails


Jeremy H.