I've got a user model for my app, and it has effectively used has_secure_password up til this point. has_secure_password necessitates a password_digest column, and herein lies my recent problem.
I wanted to create a "role" column of type string that separates admins from users - but after migrating, my password_digest got corrupted so that I get an invalid hash error whenever I try to use it in my app. In mysql everything is fine (the password_digest values haven't changed) but in rails console the value returned by User.first.password_digest is something along the lines of:
\#BigDecimal:59d0c60,'0.0',9(18)
Furthermore, unless I change the type of role from string, it gets similarly messed up (although like password_digest, it's totally fine in mysql regardless). Rolling back the migration and getting rid of the "role" column causes password_digest to go back to normal as far as rails console is concerned.
What is going on here?
Here's my database schema:
Here's the result of a sql query fed directly to mysql:
Here's the result of the same query through rails (first time):
Here's the result of the same query through rails (after first time):
Looks like your query is getting auto-explained. See the documentation here http://guides.rubyonrails.org/active_record_querying.html#automatic-explain
Related
In my project I'm using Speedment for ORM. Of course I want my code properly tested. So I decided to create an identical copy of my default database schema which I wanted to use for unit testing. In this case the name of the original schema is "project" and the name of the copy is "test_project"
My problem is that I don't know how to properly address the other database schema.
I know that, upon establishing a connection, I can use the method withSchema("test_project") to tell speedment which schema to use.
This works just fine as long as I don't have any columns identifiers in my query.
So this works:
List <User> users = userManager.stream().collect(Collectors.toList());
whereas this doesn't:
List <User> users = userManager.stream().filter(User.UID.equal(id)).collect(Collectors.toList());
It's telling me this: Unknown column 'project.User.uid' in 'where clause
I don't really understand what's going on there. (Note: I'm quite new to Speedment).
My question is: How can I access my other schema with all its rows properly addressed to it?
This was a bug in Speedment. Changing schema withSchema("test_project") is the correct way. This will be fixed in Speedment version 3.0.23.
Last night I witnessed something rather peculiar! I'd post a number of records like this one - with no problems at all; but suddenly my Rails app refused to INSERT a particular record into a particular table.
This gist details the result. You may learn that the abstract_mysql_adapter.rb does not allow the insert whereas the Rails dbconsole (really the mysql client) does indeed allow the insert?
Does anyone know what goes on? I for one is stumped :(
I truncated 2 tables in my database in MySQL (for a Rails project) so that I could repopulated it with test data. But for some reason the application is still counting how many entries there used to be (250), even though there is only 9 entries now.
I even went into the ruby console using (ruby script/rails console), then truncated using:
ActiveRecord::Base.connection.execute("TRUNCATE TABLE bars;")
but that didn't do anything different then running the query through MySQL. I am pretty confused, the only thing I can think of doing is restarting the server. I am just wondering if there is maybe another way to do this without having to reboot everything.
Printing the search to the logger I can see that the results for the bars are a bunch of nil values for where there used to be a bar_profile, but I have truncated the tables that referenced bars or bar_profiles.
So I don't get why it would just be returning what the results would have been before the tables were truncated. Except now now instead of returning actual results they are just nil.
I use Kettle for some transformations and ran into a problem:
For one specific row, my DatabaseLookup step hangs. It just doesn't give a result. Trying to stop the transformation results in a never ending "Halting" for the lookup step.
The value given is nothing complicated at all, neither it is different from all other rows/values. It just won't continue.
Doing the same query in the database directly or in a different database tool (e.g. SQuirreL), it works.
I use Kettle/Spoon 4.1, the database is MySQL 5.5.10. It happens with Connector/J 5.1.14 and the one bundled with spoon.
The step initializes flawlessly (it even works for other rows) and I have no idea why it fails. No error message in the Spoon logs, nothing on the console/shell.
weird. Whats the table type? is it myisam? Does your transform also perform updates to the same table? maybe you are locking the table inadvertantly at the same time somehow?
Or maybe it's a mysql 5.5 thing.. But ive used this step extensively with mysql 5.0 and pdi 4.everything and it's always been fine... maybe post the transform?
I just found the culprit:
The lookup takes as a result the id field and gave it a new name, PERSON_ID. This FAILS in some cases! The resulting lookup/prepared statement was something like
select id as PERSON_ID FROM table WHERE ...
SOLUTION:
Don't use underscore in the "New name" for the field! With a new name of PERSONID everything works flawlessly for ALL rows!
Stupid error ...
I'm trying to load some Rake Fixtures (rake db:fixtures:load) into a MySql database and I'm seeing some weird behaviour with AutoIncrement values. Normally this goes up by 1 for each insert which allows me to define/create tests. (BTW - normal create/insert from script works correctly).
However when I load from fixtures the id field is assigned a large random number and the autoinc value on the table is also a large number (1054583385) after the load. Has anyone else seen this?
FWIW this is on Windows XP with MySql 5.0 (I also tested with MySql 5.1, found the problem and rolled back to 5.0).
Anybody else seen this - Is this a known bug/issue?
TIA,
This is not abnormal behavior for rails fixtures. It is, by design a random hash based on the label of your fixture. See the documentation.
You can explicitly specify an ID in your fixtures if needed.
id: 1
But does it really matter? Fixtures are meant to be used for tests. The ID of your objects is irrelevant as long as the relations are there.
Here is the relevant function from the Fixtures class:
# Returns a consistent identifier for +label+. This will always
# be a positive integer, and will always be the same for a given
# label, assuming the same OS, platform, and version of Ruby.
def self.identify(label)
label.to_s.hash.abs
end