On Nov 22, 12:54 pm, Rick DeNatale <[email protected]> wrote: [...] > > Certainly. The rake migration, or migration to version, worked fine > > providing no data was written to the db from the migration. > > Because when you had those lines commented out, there was no reference > to a Url Ruby class.
Exactly, just process of elimination that those lines were problematic. [...] > Well the message is saying that there is no constant named either Url > or CreateUrls::Url defined. This is a standard Ruby message. You > probably know this but, just in case you don't, when you reference a > unprefixed constant name Ruby first looks for it in the root > namespace, and if it doesn't find it it looks in the namespace of the > current Class/Module if there is one. > > So I suspect that either: > > 1. The automatic loading of ActiveSupport didn't match up Url with > the name of the file containing the class definition for the Url > model, or See, I was thinking there was a name space problem, but "Url" was probably a poor choice. > 2. The file isn't there at the time you ran the migration because > of a different version control checkout. I haven't checked this into subversion/etc yet, but I should. > I suspect that it's the first assuming that there were no repository > operations in the mean time. > > I'm also suspicious of your nl command parameters. > > First my version of nl only takes one file name not multiples. Are > there really 3 files being concatenated together before being > numbered? I can't tell. I guess your's does work that way. hmm, "nl *" will do the whole directory for me, bog standard ubuntu, FWIW. Yes, it's a bit vague, so I won't do that in the future. > Second you seem to be executing this command from the root of the > project directory, and that's not somewhere where activesupport will > find the class files, model class files need to be in under the > apps/models directory structure. Ah, that might very well be the problem -- it's not a rails app per se, just AR at this stage. I'll probably add rails to it, but may add a ruby FOX (?) GUI as well or instead. > And on my item 2 above, it's generally bad ju-ju to depend on the > external definition of model classes within migrations. Instead you > should create the inside: Ok, this is the crux of the issue and the solution for my particular road block :) > class CreateUrls < ActiveRecord::Migration > class Url < ActiveRecord::Base > end What I did was to add: require 'url' and that fixed the problem. Although, it's black magic, to me, as to how ruby found the correct Url class, but "works for now." I don't like the way the model is defined in multiple places as shown above. However, please make your case on the bad ju-ju! It's more conventional to define the model in the migration? > def self.up > create_table :urls do |t| > t.column :url, :string > end > Url.create(:url => 'http://www.slashdot.org/index.rss') > Url.create(:url => 'http://groups.google.ca/group/ruby-talk- > google/feed/rss_v2_0_msgs.xml') > end > > This isolates the migration from the application code as it changes. But the model is "defined" twice, sorta. > The model will be scoped within the migration class. yes. > The only thing you need to include in the model class for the migration are: > The fact that it's a subclass of ActiveRecord::Base > Any association declarations needed by the migration would you expand? I'm not sure what an association declaration is. > and > any special methods needed by the migration, copied from the real > class (possibly modified) as it needs to be at the state of the > database represented by THIS migration. copied? That sounds like a maintenance nightmare...? In "real apps" are you really mucking with the db that much with migrations? It just *sounds* fragile, as described above. > > But using seeds rather than loading data in a migration is usually > wiser. Right, for now I think I'll move on, but will come back to seeds. > Data manipulation in a migration should be reserved to do > things like migrating existing data to and from a new schema when the > db can't do it for you automatically. > > HTH. > > -- > Rick DeNatale Yes, very helpful. From my perspective, it seems like the black-box magic which ruby and rails perform is sometimes inconsistent. Why does *only* that one migration, which populates the db, require an explicit class definition or import while the other migrations don't? Actually, it's working now (I think) so I'm just curious on a few points. thanks to all, Thufir -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
