I have been [trying] to use migrations with UNIX timestamps, so multiple developers can add migrations without tipping on each others toe. And hence I tried this: http://revolutiononrails.blogspot.com/2007/02/plugin-release-enhanced-rails.html It works, at least rake db:migrate. but other rake commands that deal with database is broken and hence rake db:test:prepare or rake test:units. I ran above commands with --trace enabled and I found some curious things: gnufied@xaos:~/simple_markets$ rake db:migrate --trace /usr/local/bin/rake:17:Warning: require_gem is obsolete. Use gem instead. (in /home/gnufied/simple_markets) ** Invoke db:migrate (first_time) ** Invoke environment (first_time) ** Execute environment "Hello World" #=> init.rb of enhanced migrations plugin called. ** Execute db:migrate == Alerts: migrating =========================================================-- create_table(:alerts) -> 0.0629s == Alerts: migrated (0.0632s) ================================================ == Devices: migrating ========================================================-- create_table(:devices) -> 0.0095s == Devices: migrated (0.0100s) =============================================== ** Invoke db:schema:dump (first_time) ** Invoke environment ** Execute db:schema:dump Now, lets see the flow when I run rake db:test:prepare: gnufied@xaos:~/simple_markets$ rake db:test:prepare --trace /usr/local/bin/rake:17:Warning: require_gem is obsolete. Use gem instead. (in /home/gnufied/simple_markets) ** Invoke db:test:prepare (first_time) ** Invoke environment (first_time) ** Execute environment "Hello World" ** Execute db:test:prepare ** Invoke db:test:clone (first_time) ** Invoke db:schema:dump (first_time) ** Invoke environment ** Execute db:schema:dump ** Invoke db:test:purge (first_time) ** Invoke environment ** Execute db:test:purge ** Execute db:test:clone ** Invoke db:schema:load (first_time) ** Invoke environment ** Execute db:schema:load rake aborted! Mysql::Error: Table ''simple_markets_test.schema_info'' doesn''t exist: SHOW FIELDS FROM schema_info ** All Hell broke loose here. So, in a nutshell, enhanced migrations plugin has deleted schema_info table and uses migrations_info table. But above trace makes me wonder, why db:test:clone and couple of other tasks are being invoked more the once? I don''t have a definite solution to the problem, and so i ask. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On Fri, 13 Apr 2007, hemant wrote:> > I have been [trying] to use migrations with UNIX timestamps, so > multiple developers can add migrations without tipping on each others > toe.why not simply add an iso8601 timestamp to the migration name? that way the semantics of timestamps can be gained simply be encoding the name with it rather than some random number. iso8601 has the nice property that the string sort is the same as the time ordering... ?? regards. -a -- be kind whenever possible... it is always possible. - the dalai lama --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On 4/13/07, Ara.T.Howard <ara.t.howard@gmail.com> wrote:> > On Fri, 13 Apr 2007, hemant wrote: > > > > > I have been [trying] to use migrations with UNIX timestamps, so > > multiple developers can add migrations without tipping on each others > > toe. > > why not simply add an iso8601 timestamp to the migration name? that way the > semantics of timestamps can be gained simply be encoding the name with it > rather than some random number. iso8601 has the nice property that the string > sort is the same as the time ordering... > > ??Hmm nice idea, would make them more readable. Anyway the problem I asked is fixed now, some patches back and forth. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Hi, 2007/4/13, hemant <gethemant@gmail.com>:> > > I have been [trying] to use migrations with UNIX timestamps, so > > > multiple developers can add migrations without tipping on each others > > > toe. > > > > why not simply add an iso8601 timestamp to the migration name? that way the > > semantics of timestamps can be gained simply be encoding the name with it > > rather than some random number. iso8601 has the nice property that the string > > sort is the same as the time ordering...I did implement this about four months ago: http://blog.teksol.info/articles/2006/12/13/timestamped-migrations-status It never made it into trunk/, and it shouldn't have as it didn't have tests and all. Bye ! -- François Beausoleil http://blog.teksol.info/ http://piston.rubyforge.org/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On Sat, 14 Apr 2007, François Beausoleil wrote:> Hi, > > 2007/4/13, hemant <gethemant@gmail.com>: >>>> I have been [trying] to use migrations with UNIX timestamps, so >>>> multiple developers can add migrations without tipping on each others >>>> toe. >>> >>> why not simply add an iso8601 timestamp to the migration name? that way the >>> semantics of timestamps can be gained simply be encoding the name with it >>> rather than some random number. iso8601 has the nice property that the string >>> sort is the same as the time ordering... > > I did implement this about four months ago: > http://blog.teksol.info/articles/2006/12/13/timestamped-migrations-status > > It never made it into trunk/, and it shouldn''t have as it didn''t have > tests and all. > > Bye !interesting. still, it seems like using def next_migration_number Time.now.utc.iso8601(2) end def next_migration_string(padding = :ignored) "%.s" % next_migration_number end would look much nicer than def next_migration_number Time.now.utc.strftime(''%Y%m%d%H%M%S'').to_i end def next_migration_string(padding = 14) "%.#{padding}d" % next_migration_number end in otherwords using an actual timestamp like 2007-04-14T15:04:28 in the migration name for the benefit of developers that don''t tranlate seconds since 1970 in their heads - although this change would definitely be more extensive... then again - you''ve already done the work ;-) -a -- be kind whenever possible... it is always possible. - the dalai lama --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
2007/4/14, Ara.T.Howard <ara.t.howard@gmail.com>:> in otherwords using an actual timestamp like > 2007-04-14T15:04:28Yes, but the file's ctime essentially gives us the same information, plus or minus a few seconds. Bye ! -- François Beausoleil http://blog.teksol.info/ http://piston.rubyforge.org/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On Mon, 16 Apr 2007, François Beausoleil wrote:> 2007/4/14, Ara.T.Howard <ara.t.howard@gmail.com>: >> in otherwords using an actual timestamp like >> 2007-04-14T15:04:28 > > Yes, but the file''s ctime essentially gives us the same information, > plus or minus a few seconds.not really. ctime is updated by chmod, chown, or even making links. i certainly wouldn''t want my db state determined by this time stamp. there really isn''t a concept of ''creation time'' in unix. ctime is ''change time''. the beauty of using timestamps in the pathname (in utc) is that multiple developers on multiple machines can create migrations on whatever filesystem (windows, mac, etc) they choose: do a check in - and everything will work itself out. regards. -a -- be kind whenever possible... it is always possible. - the dalai lama --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Hi, 2007/4/16, Ara.T.Howard <ara.t.howard@gmail.com>:> not really. ctime is updated by chmod, chown, or even making links. i > certainly wouldn't want my db state determined by this time stamp. there > really isn't a concept of 'creation time' in unix. ctime is 'change time'. > > the beauty of using timestamps in the pathname (in utc) is that multiple > developers on multiple machines can create migrations on whatever filesystem > (windows, mac, etc) they choose: do a check in - and everything will work > itself out.Hmm, my mistake. I did not want to replace the time stamp in the file name with the creation time (as I thought ctime meant). But anyway, point taken. Maybe it's better to put a human readable time stamp anyway. Bye ! -- François Beausoleil http://blog.teksol.info/ http://piston.rubyforge.org/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---