I'm connecting my Rails app to a SQL Server database that I do not control. One of the tables has a column of the type geometry. I can view it, and in BeeKeeper Studio just fine, but when I attempt to view the column/attribute in my Rails console, I get garbled output.
Here is some of the data as seen in BeeKeeper Studio:
{"srid":4248,"version":1,"points":[{"x":-60.161088,"y":4.53526,"z":null,"m":null},{"x":-60.160342,"y":...
And here is some of the output from the Rails console:
\x98\u0010\u0000\u0000\u0001\u0004\xE5\b\u0000\u0000\x97\xE3\u0015\x88\x9E\u0014N\xC0\x87m\
Now, Rails tells me that that string is encoded as "UTF-8" -- I find that hard to believe.
Can someone help me figure out what's wrong here? I get the feeling that either Rails is doing something bad to the string when it's taken from the database, or that I need to specify some encoding/collation in my database settings, but I don't know what.
If it helps, the database, and table's collation are both "SQL_Latin1_General_CP1_CI_AS".
Related
I have a weird problem with activeadmin. Randomly and unexpectedly some data on a resource not showed (like it has benn empty in DB). When I check the DB, all data it is on db and it is correct.
Also the data when take some .json resource is empty too.
The only solution I found for this problem is restart nginx, but it is a problem because the client not see the information on the system.
I check the logs, but I do not see any relevant information. Is there any way to get information about it for solve this kind of problems?
System versions:
Rails 5.1.3
ruby 2.2.5p319 (2016-04-26 revision 54774) [x86_64-linux]
nginx/1.10.3 Phusion_Passenger/5.1.4
Finally I found the problem but I do not understand what is wrong on it....
This are the involucrated files:
https://gist.github.com/cpfarher/bfde79dd9c3772575b03712c0a397110
The problem occured when you open the route: lines/1/edit action. After open it, data on https://gist.github.com/cpfarher/bfde79dd9c3772575b03712c0a397110#file-admin_recipe-rb is not showed.
If you change de sentence "select distinct" on line:
https://gist.github.com/cpfarher/bfde79dd9c3772575b03712c0a397110#file-recipe_fail-rb-L10
all works fine, the field on https://gist.github.com/cpfarher/bfde79dd9c3772575b03712c0a397110#file-admin_recipe-rb-L13 showed ok. But, if you use the clause with select distinct, the field it is not showed....
On the other hand if you use the file: https://gist.github.com/cpfarher/bfde79dd9c3772575b03712c0a397110#file-recipe_ok-rb instead of https://gist.github.com/cpfarher/bfde79dd9c3772575b03712c0a397110#file-recipe_fail-rb all works fine.... :|
When replicating an app to production, my POSTGIS table columns started misbehaving, with Rails informing me there was an "unknown OID 26865" and that the fields would be treated as String.
Instead of current_pos yielding e. g.
#<RGeo::Geographic::SphericalPointImpl:0x22fabdc "POINT (13.39318248760133 52.52908798020595)"> I would get 0101000020E6100000FFDD958664C92A403619DEE6B2434A40. It looked like the activerecord-postgis-adapter was not installed, or installed badly, but I eliminated that possibility by testing for the existence of data type RGeo::Feature::Point and by test-assigning
current_pos = "POINT (13.39318248760133 52.52908798020595)"
to the field - which proceeded without error but then yielded another incomprehensible hex string like the above.
Also, strangely enough, POSTGIS was working correctly within the database, e.g. giving correct results for a ST_DISTANCE query. A very limited problem thus, where writing, writing-parsing (from Point to hex format), manipulating by SQL and reading all worked, only the parsing upon read didn't.
When I tried to use migrations to ensure the database column would have the correct type, the migrations failed, giving
undefined method `st_point' for #<ActiveRecord::ConnectionAdapters::PostgreSQL::TableDefinition:0x00000005cb80b8>
I spent several hours trying all kinds of solutions, even re-installing the server from scratch, double-checking version numbers of everything, installing a slightly newer version of Ruby and a slightly older version of POSTGIS (to match my other environment), exporting the database and starting with a clean one, and so on. After I had done migrations and arrived at the "undefined method st_point" error, I was finally able to find the solution via Google, way down in a Github issue, and it's really simple:
In config/database.yml, swap out postgres:// for postgis:// in the database url. If you're using Heroku, this may require some ugly manipulation:
production:
url: <%= ENV.fetch('DATABASE_URL', '').sub(/^postgres/, "postgis") %>
So silly...
Do not forget to add activerecord-postgis-adapter to your Gemfile so #Sprachprofi's solution can run.
I am in the process of learning Rails and I've ran into an interesting problem tonight.
I was creating a migration that would require an index on the foreign key:
Whenever I would run 'bundle exec rake db:migrate', I would receive this console error:
It looks as if it was trying to create the index before it was creating the reference.
The reason I believe this is because when I change the "subject" reference to a symbol:
The migration then suddenly works as expected!
This may just be the fact that I'm a total newby, but are symbols actually processed faster by Ruby than strings are?
Just curious - thanks!
This isn't a "faster" problem, or a problem of speed. The migrations are executed one line at a time, in order. The way you had it specified before simply didn't create the column correctly, hence when it got to the line where you create the index, the names didn't match up.
My guess is, with the string version it created the column name exactly as you spelled it, "subject" as opposed to subject_id when you use a symbol. Either way, you definitely had a name mismatch between when the column was created, and when the index was being built.
Always use symbols for this in your migrations, and you should be fine. Always check your schema.rb file, or browse the database using a GUI tool, after a migration to make sure the columns got created the way you expect, and with the data types you think they are, and you should be good.
I'm developing an application layer on top of a rails app developed by someone else.
His application uses a module called request_logger to write to a table, which worked fine under ruby1.8/rails2/mysql gem, but in my ruby1.9/rails3/mysql2 environment, activerecord falls over, suggesting that the generated query is invalid.
It obviously is, all mysql relation names are wrapped in double quotes instead of backticks.
The call to activerecord itself just sets a bunch of attributes with
log.attributes = {
:user_id => user_id,
:controller => controller,
...etc
}
and then calls
log.save
So I'm leaning towards it not being dodgy invocation. Any suggestions?
mysql2 works fine for a lot of people, but it unashamedly sacrifices conformance to the MySQL C API for performance in the common tasks. Perhaps, if request_logger is low-level enough, it's expecting calls to exist which don't.
It's trivial to switch back to using mysql - give it a try, and if it works, stick with it. Remember to change both your Gemfile and your config/database.yml settings.
It turned out to be what seems to be a change in behaviour between rails 2 and 3 (we have the same setup working fine in rails 2)
We use database.yml to specify an (empty) "master" database and then feed in our clients with shards+octopus.
The master db is sqlite for simplicity, and it seems that activerecord was feeding off requests formatted for sqlite to the mysql2 shards, regardless of their adaptor type.
I am running ruby 1.8.7, rails 2.3.5 and mysql database.
The record in mysql database looks like
'In Light of Egypt’s Internet Block, U.S. “Kill Switch Bill” Raises Eyebrows'
However, the rails app displays it as :
In Light of Egypt’s Internet Block, U.S. “Kill Switch Bill†Raises Eyebrows
The mysql connection in my database.yml is set as utf8
In my environment.rb, I also tried with and without explicitly setting
config.i18n.default_locale = :en
None of these things worked.
Any help would be great.
Thanks
Edit: Clarification:
When I go to mysql commandline and query, I get the following record back:
Light of Egypt’s Internet Block, U.S. “Kill Switch Bill” Raises Eyebrows'
When I display the same string in rails app, it appears as:
In Light of Egypt’s Internet Block, U.S. “Kill Switch Bill†Raises Eyebrows
Mysql database was created with a default encoding of latin1 which caused the problem.
I had to recreate the database and recode existing data in UTF8. Recoding didn't exactly clean it up
but all new data is stored in UTF8 format now.