On 29 Oct 2008, at 10:54, Tom Hughes wrote:
Shaun McDonald wrote:I have therefore looked into upgrading rails to the latest version of rails, which is currently 2.1.2. There is minimal changes required. In doing so I will bring the last 3 externals into the osmsvn, as they will probably eventually disappear with the majority of rails being moved from svn to git, and are unlikely to be updated in svn. It will also make it faster to get updates. File_column needs to be updated slightly for Rails 2.1.2.When I tried moving to 2.1 before there were significant problems which led me to abandon the attempt - have you verified that there are no such problems now?
Initial tests haven't shown any problems at the time of commit, where I was just using the old db. I will be embarking on more thorough testing to see if there are other problems.
I have now run a rake db:migrateFirst problem that I have now found, is with limit option in integers in the migrations (version=1) related to the following change:
http://rails.lighthouseapp.com/projects/8994/tickets/420 It is this line that http://trac.openstreetmap.org/browser/sites/rails_port_branches/api06/db/migrate/001_create_osm_db.rb#L113change_column "gpx_file_tags", "id", :integer, :limit => 20, :null => false, :options => "AUTO_INCREMENT"
that gives the error: No integer type has byte size 20.From http://api.rubyonrails.org/files/vendor/rails/activerecord/CHANGELOG.html : Added that the MySQL adapter should map integer to either smallint, int, or bigint depending on the :limit just like PostgreSQL [DHH]
http://blog.smartlogicsolutions.com/2008/06/24/rails-21-broke-my-mysql-foreign-keys/Do you know what the best solution here is. I can no longer see an option to be able to specify the width of an integer field, however this don't know the significance of this. Choosing the right type of integer seems to be more important.
Unfortunately it was a while ago and I can't remember exactly what the problems were, though I think they may have been related to the fact that we have some models without primary keys. Maybe the other changes in 0.6 mean those have gone away though?
It could be that some of them have been solved between Rails 2.1 and 2.1.2.
BTW most of our plugins don't come from the main rails repository, so the move of that from svn to git shouldn't be relevant. Right now you've actually left the repo in a broken state with this change as you've committed the plugins but not removed the external definitions so svn update is trying to put two things in the same place.
Actually it a problem with svn not being able to cope with the fact that I have deleted the externals property, and placed something with the same name there. The svn property doesn't appear appropriately in the diff, that svn locally gets during the update, so is unable to remove the externals. Delete the vendor/plugins folder then svn update again, and it should all work.
I will also be updating the various config files to the newer Rails 2.1 format, so that you will be able to do sudo rake gems:install and all the gems that you need will be installed. rake gems will tell you which gems are required and whether they are installed. You will need to make sure that you have gem 1.2 or later. Please also be warned that you will need to update your gems using sudo gem update. It should also be noted that Rails 2.1 introduced a change in the way migrations and their version numbers are handled.That is optional though, and I suggest we don't use it as it will be very confusing to have a mixture. Not to mention that the ability to cherry pick updates in the 2.1.x scheme scares me witless.
It does have the advantage of not having to renumber all the migrations with every resync or branch.
Oh, and to answer your question in libxml.rb, yes the error handler is needed or libxml writes out of memory errors to the standard output and exits uncleanly I believe. Believe it or not I didn't write the handler for my own amusement.
I've added a comment to this effect for future reference in revision 11547.
Shaun
Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu/
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev
