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.
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.... :|
I've a problem with Neo4jrb 8.1.1, Rails 5.1.1, Neo4j 3.2.0 CE
I have a City model with an Int id, the DB is read only with data imported from csv files.
What should I declare to get rid of the error?
So far, I thought that declaring
id_property :id
property :name
would be fine but it doesn't work.
Overall, I'm annoyed with these new migrations files because the Neo4J DB is already done, I'm not supposed to write or modify indexes or constraints.
What's the error message you're seeing? I imagine you can solve the issue by creating an initializer and manually adding the relevant constraint(s) to the ModelSchema. Something like Neo4j::ModelSchema.add_defined_constraint(City, :id). It's also possible that this could be done inside the Model itself. Some experimentation should solve the problem.
See the source code for more info:
https://github.com/neo4jrb/neo4j/blob/8.1.x/lib/neo4j/model_schema.rb
http://www.rubydoc.info/gems/neo4j/Neo4j/ModelSchema
I would very much like to use the mongo geoNear command as discussed here.
Here is the command I entered in my rails console with the accompanying error message.
MongoMapper.database.command({ 'geoNear' => "trips", 'near' => [45,45]})
Mongo::OperationFailure: Database command 'geoNear' failed:
(errmsg: 'more than 1 geo indexes :('; ok: '0.0').
I can not make sense of the error message, it is supposedly impossible to have more than 1 geo index and I am certain that I have only created one.
Based on this stackoverflow question I believe I am wording the query correctly. Does anyone understand that error message? How would I go about destroying and recreating my indexes?
I am using rails 3.1 with mongodb v2.0 and the mongo ruby gem v1.5.1.
I really asked this too soon, maybe I should delete it? Somehow there were in fact too many geo indexes, because deleting the index and recreating it fixed the problem.
MongoMapper.database.collection('trips').drop_indexes
Trip.ensure_index [[:route, '2d']]
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.