Active record association not working with string id

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.

Mislav

Hey,
Thanks for the reply.Below I’m writing the code which is responsible for the action I have posted.

class Post < ActiveRecord::Base
has_many :comments
end

class Comment < ActiveRecord::Base

belongs_to :posts
end

class CreatePosts < ActiveRecord::Migration
def self.up
create_table :posts |, :id=>false do |t|
t.string :id , :null => false
t.string “title”

end

execute(“ALTER TABLE posts ADD PRIMARY KEY (id)”)
end

def self.down
drop_table :posts
end
end

Is the procedure wrong or something?The same way worked when the primary key id is a string.

Thank you.
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.

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)

Fred

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?

RSL

Yeah. Are non-integer primary keys actually supported?

They're *meant* to be, but given how much more common it is to use
integer keys, it wouldn't be surprising if a bug had crept in.

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.

My plugin is available here for checkout:

   svn://cho.hapgoods.com/groupsmarts/uuid_primary_ke

and here for browsing so you can see just how simple it is:

   http://cho.hapgoods.com/projects/groupsmarts/browser/uuid_primary_key

-Chris

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 :slight_smile: 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 :slight_smile:

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 :wink:

"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?

Yeah It would be my pleasure to help you in any such issues…
kranthi.