[...]
> 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