Adding fields: same or separate table?

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.

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 protected] wrote:

Jay L.


engine-users mailing list
[email protected]
http://lists.rails-engines.org/listinfo.cgi/engine-users-rails-engines.org

  • J *
    ~

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.