Fun with saving things in Ruby on Rails

7 Comments

1. 

   Robert Thau

   October 18, 2007 at 9:15 pm

   One approach would be to forgo the validation on addresses.user_id, and prevent “addresses of no user” with a NOT NULL constraint at the database level. (I’m assuming that you never reassign an address to a different user, so you don’t need validations to help the UI with that).

   BTW, this schema illustrates why it’s hard to come up with a completely general solution for getting fixtures to work with foreign key constraints. Let’s say that your fixtures include a user and that user’s most recent address. These are two database rows, each of which has a foreign key on the other. The fixtures machinery has to insert one of these rows into the database first; whichever row it is, the row in the other table won’t be present yet, and the foreign key will be invalid. When deleting fixtures, you have the same problem in reverse; you can’t delete either row without invalidating the FK in the other.

   In schemas without this kind of circularity, there’s an easy (though ugly) workaround: order the tables so that each has foreign keys only on tables that were already named (something like “users, blogs, posts, comments”), put something like this in your test_helper

   def self.use_all_fixtures
   fixtures :users, :blogs, :posts, :comments
   end
   

   and have all your tests “use_all_fixtures”. But with the circularity, the only workable thing I can think of would be to find a place to hook the fixtures machinery to delay setting the FK’s on insertion, and null them out on deletion (paying due attention to whichever FK’s have been declared NOT NULL)…
2. 

   Erik Kastner

   October 18, 2007 at 10:03 pm

   How about, just for the validation, using a known-good user-id (maybe 1 for the admin or whatever). That way that constraint is satisfied. If the user is also valid, save it, replace the dummy id in address and save that one. If either is valid, combine the .errors arrays and show them to the users.
3. 

   Erik Kastner

   October 18, 2007 at 10:08 pm

   *If either is invalid 🙂
4. 

   Robert Thau

   October 18, 2007 at 10:33 pm

   Sticking in a “known-good”, but incorrect, user ID would scare me a bit — it opens you up to bugs in which the address object gets saved before its user ID has been changed from 1 (or whatever) to the correct value.

   BTW, yet another approach would be to put the check for a non-nil address.user_id in a before_save callback on the address class, rather than in validations.

   (And while I’m at it, another approach to fixtures-with-fks would be to use db-specific voodoo to disable the foreign key constraints while the fixtures machinery is messing around, and reenable them after it’s finished — tricky, but still a game that real DBAs sometimes play when using, say, Oracle export/import on tables full of live data…)
5. 

   Rafe

   October 18, 2007 at 10:42 pm

   As far as database constraints go, you can have foreign keys on both sides but you have to allow one or the other to be null. current_address_id is the one I allow to be null, since all addresses need an owner, but a user may not have a current address.
6. 

   Allan Beatty

   October 18, 2007 at 11:57 pm

   Addressing only the database design issues and not the Ruby-specific questions.

   Are current addresses and previous addresses really the same kind of thing? If each user has one & only one current address, could it be a property of the user object, with previous addresses by themselves in a previous address object? Then there’s no circularity, as the user object has no foreign key into the previous address object.

   I had this very exact situation today in a database I was training some new employees on. The above is how I drew the conceptual data model diagram. (I’m afraid the actual implementation isn’t so clean.) We don’t need to keep track of as much data for previous addresses as we do for current ones, which also suggested storing them separately.
7. 

   bryan

   October 19, 2007 at 1:01 am

   I don’t want to save anything if there are problems with either of the objects. So if the address is invalid, I don’t want to save the user.

   My question is, “why not?” The cost is relatively inexpensive; sure, you’re burning a PK increment, but you’d need to burn through too many to care about before you run into trouble.

   I’m assuming that your address model is validating and will raise in the event of invalid address…

   I think you had it correct; you can create a new model to interact with User/Address, then here’s your method:

   ...
   def create
   newGuy = User.create ( /assign values to fields / )
   
   newGuy.save
   
   newAddress = Address( /assign values to fields /)
   
   begin
   newAddress.save
   rescue
   newGuy.destroy
   raise 'Invalid address... start over, you pig!'
   end
   end
   ...