How to prevent same migration timestamps when scripting?

Hi,
recently i had a need to generate lots of migrations and models from
csv fixtures. I wrote a generator script.
The problem is, it runs so “fast” that all migrations are of the same
timestamp, so i cant migrate.

#main generator file

def manifest
record do |m|
prepared_migrations.each do |key, value|
value.shift
m.migration_template ‘lib/migration_template.rb’, ‘db/
migrate’,
:migration_file_name => “create_#{key.downcase}”,
:assigns => {:table => key, :colums => value, }
end
end
end

migration_tempate.rb

class <%=“Create#{table.capitalize}”.underscore.camelize %> <
ActiveRecord::Migration
def self.up
create_table :<%= table.downcase %> do |t|<%- colums.each do |
value| -%>
t.string :<%= value%><%- end -%>
end
end
end

Prepared migrations is a hash “table_name” => [“column_name”,
“column_name”, … ]
is there a “take a break” option in migrations? or do i have to
migrate into one BIG migration?
best regards
DarkTatka

 prepared_migrations.each do |key, value|

migration_tempate.rb

Prepared migrations is a hash “table_name” => [“column_name”,
“column_name”, … ]
is there a “take a break” option in migrations? or do i have to
migrate into one BIG migration?

How many is a lot? If it’s not that many and you don’t do it that
often just sleep for one second up in your loop when you’re generating
the files. Or fake it by checking the file name and if there is one
with the same timestamp add a second.

Or better yet, start with Time.now.to_i and then for each migration
add one to that value and use that…

-philip

On 13 Aug 2008, at 17:30, DarkTatka wrote:

Hi,
recently i had a need to generate lots of migrations and models from
csv fixtures. I wrote a generator script.
The problem is, it runs so “fast” that all migrations are of the same
timestamp, so i cant migrate.
Evil thought: overwrite Time.now by increasing it by one second after
each migration is generated. mwahahahahaha.

Fred

I consider it a bit of a “hack”, but will be using it until i find
something better (or someone else here does)
Isn’t what your doing a bit of a “hack” anyway? So what’s your point,
hehe.

Please don’t take that the wrong way. I was just kidding around.
However, the older incrementing migrations had other (maybe more serious
issues) and I don’t think it was intended for multiple migrations to
happen within the same second. Although that is a known limitation. So I
wouldn’t consider generating your own time stamps any more of a “hack”
than the problem you’re trying to solve. It sounds like a workable
solution to me.

DarkTatka wrote:

Philip,
thanks for sugestions, but when i insert “sleep 2” anywhere in the
record block,
it 1) takes incredibly long,
2) migrations are still timestamped the same, since the record
block “records” with waiting,
but “plays” without it.
generating my own timestamps should work.
I consider it a bit of a “hack”, but will be using it until i find
something better (or someone else here does)

PS - lot means 100+, has to run once.

Philip,
thanks for sugestions, but when i insert “sleep 2” anywhere in the
record block,
it 1) takes incredibly long,
2) migrations are still timestamped the same, since the record
block “records” with waiting,
but “plays” without it.
generating my own timestamps should work.
I consider it a bit of a “hack”, but will be using it until i find
something better (or someone else here does)

PS - lot means 100+, has to run once.

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