Dynamic attributes on a model

[IsBOF]

We are in the middle of developing an application where we need to be
able to add and remove attributes to a model when it is running. We
have no problems removing the attribute with:

ActiveRecord::Schema.define do
remove_column [table_name], [new_colum_name]
end

but session that are already have loaded the object fails on update,
because the attribute does not exits in the database.

Any one have any good idea on how to update the object already in
session with the new schema information?

A side note: I know it is normal to move information like this out into
its own table/model object, but because of performance issues we would
like to keep all information in one table.

IsBOF

[Frederick Cheung]

Do you have to stick the whole object in the session or could you just
store its id instead?

Fred

--
Posted via http://www.ruby-forum.com/.

[Andrew Stone]

Any one have any good idea on how to update the object already in
session with the new schema information?

Don't know your exact scenario (have data you want to preserve in the object, etc...) but maybe class.reset_column_information with an object.reload ... or something like that?


--
Andrew Stone

[Trevor Squires]

Okay,

don't think I'm picking on you or anything but it's *really*
frustrating to see this sort of thing.

Either your schema changes happen infrequently enough that a migrate/
deploy is a reasonable strategy *or* you are seriously abusing the
relational model. I rarely feel issues have no middle-ground but in
this instance... it's one or the other.

Now, maybe you've *really* done your homework and *proved* (in a way
to ensure Zed Shaw wouldn't tear you a new one) that the *only* way
to get the performance you require is to batter your schema. But I
suspect that's not the case and you simply haven't figured out the
best way to solve your problem.

I'm available for mentoring and code reviews and my rates are
reasonable so feel free to contact me off-list.

Of course, I've probably offended you so I'm not expecting an email -
so find someone, *anyone* good, to review your code show you what you
need to be doing in your particular case.

Good Luck
Trevor

[IsBOF]

thanks for the suggestions.

1. We use only the id in the session, it looks like rails caches some
information so it we get the "old" object schema with the field we have
removed back.

2. reset_column_information - really resets the object information to
the point where it is unable to find any attributes or has_many on the
object.

Trevor: We have tried with a "correct" relations model. This result in
a unacceptable performance issues (some thing like 200 updates on a
submit). And the remove/add of column happens frequently.

Best regards,

Rasmus

[Alex Wayne]

IsBOF wrote:
> thanks for the suggestions.
>
> 1. We use only the id in the session, it looks like rails caches some
> information so it we get the "old" object schema with the field we have
> removed back.
>
> 2. reset_column_information - really resets the object information to
> the point where it is unable to find any attributes or has_many on the
> object.
>
> Trevor: We have tried with a "correct" relations model. This result in
> a unacceptable performance issues (some thing like 200 updates on a
> submit). And the remove/add of column happens frequently.
>
> Best regards,
>
> Rasmus

Rails was really not designed to handle this. In production mode, it
caches the classes, which include schema info for Models. You could
turn off cache class caching for production but that would create a huge
performance drop.

[Scott Becker]

Haha, yep, something doesn't sound right... :)

Rasmus - maybe if you described the use case scenario a bit, we might be able to figure out a better strategy than adding/removing columns at run time. I can't imagine ever wanting to do this.

--
Scott Becker
Electro Interactive, Inc.
Office: 813-333-5508
http://www.ElectroInteractive.com