I generated a scaffold against a legacy SQL Server database view that has a text primary key with no id column. I have set_primary_key "Gift_ID" in the model but Im getting an error on the show method.
I can list the records okay but when I click on the show link, it errors out. It appears to be using id to look up the record even though I have set_primary_key in the model. Here is the complete text of the error displayed;
NoMethodError in PledgesController#show
undefined method `eq' for nil:NilClass
Rails.root: /home/steve/RubymineProjects/otatest
Application Trace | Framework Trace | Full Trace
app/controllers/pledges_controller.rb:16:in `show'
Request
Parameters:
{"id"=>"PL-24681"}
Show session dump
Show env dump
Response
Headers:
None
Can anyone shed some light on why it is still trying to use "id" as the key?
Thanks for any help!
I solved my problem, so I thought I'd answer my own question in case it helps someone else;
I gave up on using the set_primary_key option in the model and added an "id" field to the view in my legacy system (SQL Server) using a key field in the data. That solved the id problem.
I also found that the generated scaffolding field names are case sensitive. So I used the view to set all field names to lowercase. You could make sure your scaffolding case matches the legacy field names, but I found that it's easier to just set them all to lower case.
One more thing; I had a few legacy boolean fields that had a "?" on the end of the field name, the scaffolding did not like that either, so I removed the "?" in the view.
Bottom line, building a Rails app on top of a legacy system has it's challenges. I discovered most my problems by migrating the table to the legacy database and examining the way it created the fields then modifying my view to match.
Related
This is closely related to Rails ignores columns from second table when using .select, however that question doesn't go deep enough.
As per the above question, I have a complex query being run from one of my ActiveRecord Models which generates a kind of 'report'. It is basically a giant table of the primary Model's attributes as well as a few other attributes from related tables.
The query itself, works. I have verified that the resulting SQL executes correctly and when pasted into a SQL terminal I get the results (and columns I want). Unfortunately there is proprietary information in the models that I can't share here, and the Query is too complex to obfuscate. But To give an idea of what I am doing, this is the start of my ActiveRecord Query: permits = Permit.select('*').joins("LEFT JOIN crosstab (' ....
I have pasted the ActiveRecord Query (above) into the Rails console and not only does it execute perfectly; but the additional attributes (not asssigned to any model or association in my app) can be queried, just fine - exactly what I want:
>> permits.first.applicant_name
"Gordon Ramsay"
The problem is that when I execute the code in the rails app (executed from the browser) I can access the attributes of each permit and its associated models ok, but the additional selects on permit raise a NoMethodError.
I cannot understand why the Rails console will let me plug the commands in and work, but when I run the same code in only of my application's methods, it raises an error.
The question above seems to deal with this closely, and the accepted answer suggests trying something out in the console; but why would the console and the Rails app itself deal with this same code differently (since I am under the assumption that the Rails console is an instance of the Rails application?
Does anyone know:
Is my assumption about the ActiveRecordRelation omitting the non-model attributes correct?
Why does the Rails console allow me to do this query and call the 'extra' selected columns but Rails will not.
Is there a way I can do what I need to do - perhaps creating a proxy object or casting the Permit model to some other ActiveRecord Object that doesn't 'ignore/drop' the extra attributes from the select?
I'm using Mongoid 4.0.0 with Rails 4. My models map tables in another application, and I have no control over the field names.
One of the models has a field named id, which is getting coerced into Mongo's _id field. For example, when I insert a document with an id value of "something" I get
{_id:"something", id:null}
instead of
{_id:ObjectId("<hexstring>"),id:"something"}
Is there any way to avoid this coercion, make Mongoid not conflate the two fields, and leave my id field alone?
As I said, renaming the id field is not an option.
Thanks!
[edited]
This is definitely not a MongoDB issue. It must be in Moped or (my guess) Mongoid.
I've tried changing the params key from :id to :_rid but this is still happening. I'm going to check out aliases, but from my first pass I don't think they're going to help -- they appear to go the wrong way.
This appears to be hardcoded into Moingoid and a pervasive assumption throughout. It's annoying enough, though, that I might come up with a patch to allow users to override the key field on a per-model basis.
Oh well.
I have a Rails 3.2 app that uses a legacy database so most tables and ids aren't in the Rails format. The whole app uses set_table_name and set_primary_key, and as we've recently migrated to 3.2 from 3.0, we're getting a whole bunch of deprecation warning.
The suggestion is to use self.primary_key = 'another_key', however for some reason this approach is not working.
I'm using FactoryGirl to build and save the models, and when it tries to save the model it gives me the following error: (on an Oracle database)
ActiveRecord::StatementInvalid:
OCIError: ORA-01400: cannot insert NULL into (sql string)
Basically from what I understood, the custom primary_key is not being correctly set, and ends up as being nil, which obviously will raise this error. The SQL string has the correct custom PK, but it seems that the value being passed to it is null.
Is there any fix for that? If I keep the deprecated set_primary_key it works flawlessly, but I know it's depreceted and I don't want to keep using it.
I found the problem. Turns out that in some files I was doing
self.primary_key = :some_key
This was failing because I'm passing a symbol, and not a string. Changing :some_key to string everywhere solved the issue.
everyone. So, I'm working on a basic Rails 4 application for practice, and I have a model for FriendCircle and a model for FriendCircleMembership. (the FriendCircleMembership's corresponding table is basically a join table).
In the console, I'm able to create a new FriendCircle object while passing in :friend_circle_memberships_attributes. This successfully inserts a new FriendCircle row into my table as well as inserting the proper rows into the FriendCircleMembership table.
The WEIRD thing is that, even if i comment out that the FriendCircle accepts_nested_attributes for :friend_circle_memberships, it still works. Is this because i am whitelisting it as a permission in the controller?
The other issue is that, even though i can successfully make the nested objects via the rails console, when i try making it through my html form it says my friend_circle_memberships_attributes is an unpermitted parameter. Not sure why this is happening. I check the incoming parameters and they look fine.
any help would be SWEEEEET. thanks.
I determined what the error was: One of my controllers for a nested attributes was validating the presence of the id of the controller it was nested under.
I'm assuming the validation occurs before an id is created, which makes sense, but im not 100%. So i just took out the validator and things worked.
We have a simple site model with single table inheritance sites(id, type, title, address) where type can be "Home" or "office". When we were on Rails 2.3.5 we could do Site.last.title and it would give the title. However, on Rails 3.2.6, when we do Site.last.title it give us the value as the type column instead.
Is it possible to get the value of the title instead of the type?
If you are trying to get the newest value of a table, It is better to find it by created_at column. By default, using Site.last, Rails will search by primary key (ID), which is fine most of the time. However, if for any reason you need to change an ID on an existing record, your SQL will not return what you expect.
So, it is better to do something like:
Site.order("created_at").last.title
Regarding the problem you are facing, I think the problem is related to the type and not the title. Anyway, I recommend you to set the newest site in your controller and then call it in your view.
#controller
#site=Site.order("created_at").last
#view
#site.title
I hope it helps...