I'm just starting with the UserEngine on a new app. I'm going to have a bunch of other per-user data: phone number, AIM name, etc. Would it be better to add these as fields to the Users table, or to say that User :has_one Profile, and put them in @user.profile? I've seen some people have trouble with has_one syntax but I haven't tried either way myself yet. Any advantages/disadvantages to either approach? After noticing that the UserEngine down-migration deletes Users, I feel uncomfortable trusting it to leave my fields alone, but conceptually, these fields do belong to User. Jay L.
on 2006-02-04 22:14
on 2006-02-04 22:21
The only situation where the user table would be deleted given a standard login/user engine setup would be if *you* ran: rake engine_migrate ENGINE=login_engine VERSION=0 ... which is a pretty specific command. Because of this I'd say that it's quite safe to place your extra data in the user table where it almost certainly belongs. There are probably many simpler and more likely ways to trash your database than this. - james On 2/4/06, Jay L. <email@example.com> wrote: > Jay L. > > _______________________________________________ > engine-users mailing list > firstname.lastname@example.org > http://lists.rails-engines.org/listinfo.cgi/engine... > -- * J * ~
on 2006-02-04 23:43
On Sat, 4 Feb 2006 20:20:42 +0000, James A. wrote: > The only situation where the user table would be deleted given a > standard login/user engine setup would be if *you* ran: > > rake engine_migrate ENGINE=login_engine VERSION=0 Ah, ok. I haven't used migrations before, so I didn't know what would have happened if, say, I'd had a pre-existing User table, and used migrations to add the new fields for LoginEngine and UserEngine. Looking more closely, I'm guessing I would have had an error - if my table already had a schema version, then 001_initial_schema wouldn't have run, and if it had, it's only creating tables, not adding fields... This does make me think that some future version of Engines might want to handle just such a case - an engine that either creates its own table, or adds fields to an existing table. But that might be tricky since you can't version parts of a table. Ah well. I guess that, in turn, depends on fancier inheritance in Rails. Jay L.