Hello,
I'm stuck with an issue where the active record associations are not
working.
I have created the required migrations.In my migrations I need the id
to be a string and not an integer as the usual rails id.I have
declared the associations in the models.
But for some reason I'm not able to access the data using the regular
relationships .
I get the error as below:
NoMethodError: undefined method `product_skus' for #<Product:
0xb6fe5630>
from /root/Desktop/trunk/vendor/rails/activerecord/lib/
active_record/attribute_methods.rb:205:in `method_missing'
from (irb):25
I'm working on rails 2.1.0
Please let me know if there is any creep we can do to this.
Any help appreciated.
kranthi
Developers are rarely using primary keys which are not auto-generated, incremental integers. There might be a bug with associations in that case, but you must take proper steps to report it. Open up a ticket in Rails’ bug tracker and provide ActiveRecord code that creates the association, structure of your tables and generated SQL on association lookups that fail for you.
Still, judging by your error message, I think that your problem may be in user code, not in the framework.
Developers are rarely using primary keys which are not auto-
generated, incremental integers. There might be a bug with
associations in that case, but you must take proper steps to report
it. Open up a ticket in Rails' bug tracker and provide ActiveRecord
code that creates the association, structure of your tables and
generated SQL on association lookups that fail for you.
There are at least some tests that cover associations with string keys
(which I wrote after haven broken stuff in that case :oops).
Hard to say without seeing any of the actual code though (and errors
in that area tend to result on borked queries rather than errors like
the one below)
Just curious, is it actually a bug when a user decides not to use
Rails' convention of auto-incrementing integer as id and something
breaks as a result?
Non-integer keys have been very well supported, up to at least 2.0.2.
I wrote a plugin that uses UUID primary keys and have only had one
problem in the past two years (and Frederick fixed it quickly). And
most plugin providers also support non-integer primary keys (two years
ago, for example the developer of acts_as_ferret retrofitted string
keys in short order).
And the support is not just a situation where you can hack Rails code
to do it. It's actually pretty easy... Rails provides methods to
define the primary key name and in the remainder of the code no
assumptions are made as to the type value used for the PK. My plugin
is less than 60 lines of code but the reality is that you could write
your own in ten lines of code.
There are two caveats that I don't expect will be addressed by Rails:
migrations with deviant primary keys and Foxy Fixtures with deviant
primary keys. Although in both cases my plugin addresses the problems
nicely -but with monkey patches. In fact, in the case of Foxy
Fixtures, I've restored about 90% of the Foxy Functionality when using
UUID primary keys.
Given the very high level of support for string keys already in place,
it would be a shame to break it now.
I won't get into the religion of meaningful keys, but know that many
programmers prefer to have their PKs correlate to "real world"
attributes that are not integers. This is particularly true in legacy
applications.
PS - I will go so far as to say that in an ideal world, Rails would
offer support for UUID primary keys out of the box. It is dead simple
and provides many advantages in distributed applications -Adobe Air
and other apps with standalone clients come are good examples. And
UUID are very analagous to the auto-incrementing integers Rails
already uses: they can be generated at the database and they are
guaranteed to be unique.
Non-integer keys have been very well supported, up to at least 2.0.2.
I wrote a plugin that uses UUID primary keys and have only had one
problem in the past two years (and Frederick fixed it quickly). And
most plugin providers also support non-integer primary keys (two years
ago, for example the developer of acts_as_ferret retrofitted string
keys in short order).
As I mentioned earlier, these are meant to work, and any bugs
resulting from non-integer keys are just that. Bugs There's no
reason to remove them.
I won't get into the religion of meaningful keys, but know that many
programmers prefer to have their PKs correlate to "real world"
attributes that are not integers. This is particularly true in legacy
applications.
Natural keys aren't something that we want to encourage. Anyone who's
been told "sorry, you can't change your email address as it's the pk
of the user table" will understand. But UUIDs and other opaque
strings can and should be supported
PS - I will go so far as to say that in an ideal world, Rails would
offer support for UUID primary keys out of the box. It is dead simple
and provides many advantages in distributed applications -Adobe Air
and other apps with standalone clients come are good examples. And
UUID are very analagous to the auto-incrementing integers Rails
already uses: they can be generated at the database and they are
guaranteed to be unique.
If you'd like to prepare a patch for this, we can take a look at it
for inclusion. If it's non-intrusive and simple enough, perhaps we
can include it. Though your urls must be HUGE
True dat. But I've been dreaming of a git-like approach that
(optionally) takes just the first six or seven characters -enough to
practically ensure uniqueness. That way smart clients could send big
nasty request URLs but a browser-driven app could generate "less ugly"
URLs. As always with string keys, performance of big random keys and
a LIKE construct could be an issue...
Anyway about my plugin-that-dreams-of-being-in-core... I've got some
questions about how to go about INCREMENTALLY bringing in the
functionality. Right now I see the task broken into three
components. And some of them aren't really baked yet and I'm not the
right one to finish the job:
**1. Core support in ActiveRecord::Base for generating a UUID string
(currently 36 characters) on create and using that for the primary
key: DONE (requires the uuidtools gem). This gets you 95% of the
value and is, frankly, a trivial implementation. But without #2 and
#3 below, it probably is going to seem broken to many.
**2. Support for Foxy Fixtures: STARTED. I allow the generation of a
stable UUID from the fixture label (tricky and cool!) but I have not
added support for an automatic application of these UUIDs to keys in
the fixture files themselves. And there is a fundamental problem
here...
**3. Support for Migrations: STARTED. I provide new types that are
just syntactic sugar. There are some (minor) long-term issues here as
well.
So, really only #1 is ready for prime time. FF and Migrations still
need help. If I go to the trouble of putting this up on GitHub,
anybody want to help take it over the finish line?
There's no
reason to remove them.