In reference to the post about My First Patch to the Rails trac I mentioned in the edit of the post that I emailed the maintainer. There’s been no response, unfortunately.
So I’ll post the patch here so it’ll get a bit more visibility and hopefully Oracle users can find it helpful in speeding up rake db:migrate on Oracle systems with a lot of indicies.
I’ve submitted my first patch to the Rails trac today to speed up the OracleAdapter#indexes method (used in migrations). A client at work uses Oracle and in the production environment this method was taking upwards of 45 seconds to run per table!One of their DBAs gave me the SQL there, so I can’t take the credit, I just submitted it.
I hope it’s accepted. Incidentally, it works and has saved me a lot of time with migrations.
Edit: Yeah, turns out that since turning these adapters into gems patches for them shouldn’t be done through Rails trac. How irritating, but whatever. I’ve sent the patch do the current maintainer for review.
It’s coming.
The new REST helpers are most appreciated.
Moving the proprietary adapters to a separate repository without any tests makes it impossible to modify the adapters. That irritates me a lot. How are we supposed to test patches that improve thing?
Yesterday at work I deployed the ‘Oracle Project’ to the customer’s staging server. The only hiccup was (I think) a problem with the renumbering of migrations that was coming from two branch merges and a merge into trunk. I apparently misnumbered one and a critical migration wasn’t run. Oops.
I’ve noticed that at the end of rake db:migrate that Rails rebuilds the db/scema.rb file (nothing new there) except with Oracle each table takes about 45 seconds to process! We’ve got about 35 models! That’s almost 25 minutes! What gives?
Anyways, Oracle is conquered and it is my bitch.
At work I've been struggling with making one of our projects play nice with Oracle. I got Oracle XE installed through Windows XP in Parallels and just couldn't make my tests work. I kept getting errors that Rails couln't insert a nil value into a non-nil field (id).
What this eventually boiled down to is Rails fixtures MUST have an id attribute on them or you may run into errors! This was hidden behind the scenes since heretofore we were using auto_incrementing MySQL fields. To get this behaviour in Oracle one must do
(done by Rails automatically, normally) or set up a Trigger (not done by rails, and would have to be done in a create_table migration).
However, fixtures bypass the normal ActiveRecord::Base#create call and just does a raw execute insert into... Which means there's no value for id, unless it's specified in the fixture. This kept me at it for hours today and I only found it by hacking the fixtures source to make it print in the logs what it was doing!
Let this be a lesson! Always put in ids even if you don't care about their values.
Powered by WordPress