[OSM-dev] Rails api06 branch updated to Rails 2.1.2
Shaun McDonald
shaun at shaunmcdonald.me.uk
Wed Oct 29 15:56:15 GMT 2008
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:migrate
First 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#L113
change_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 (tom at compton.nu)
> http://www.compton.nu/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20081029/49aa226b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2433 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20081029/49aa226b/attachment.bin>
More information about the dev
mailing list