Og's answer to migrations?

I was just thinking about this, say you’re building an address book app.
At first you give every address one phone number, but people start
complaining and so you want to add a separate table for phone numbers so
an address can have n phone numbers. Naturally you want to keep your
data. Does Og have any functionality whatsoever to assist here?

If you’re familiar with Og, how would you do this?


Ein Fuchs muß tun, was ein Fuchs tun muß
[email protected]

just write a small script:

for u in User.all
PhoneNumber.create(u.phone, u)

then just call alter table drop column to remove the uneeded column.


Wouldn’t the success of this example depend on the “PhoneNumber”
relationship with “User”?

Also, I’m a little curious about how (or indeed IF) different instances
structures are associated, linked and otherwise understood.

A long time ago, I had a question about how to explicitly open two
tables of the same class – Migration is a good use case for that. I
really get a comfortable answer. In fact having two Og instances of the
same Object type tended (at that tiem) to be problematic.

a = PhoneNumber.new( “/usr/pathone” )
b = PhoneNumber.new( “/usr/pathTwo” )

  Aggregated_customers = PhoneNumber.new( "/usr/pathall" )

Is that any easier these day?


This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs