I need to make some changes to the code, which was written by another developer. One of them is to use the ST_DISTANCE_SPHERE function in a query. I added this function to the database following this link
But I realized that it's not enough, cause the application is using Doctrine. I'm not using Doctrine in my usual applications, so I'm not pretty sure what should I do.
Until now I ran composer require creof/doctrine2-spatial in console
And I added to config/package/doctrine.yaml below code
doctrine:
dbal:
url: '%env(resolve:DATABASE_URL)%'
types:
geometry: CrEOF\Spatial\DBAL\Types\GeometryType
point: CrEOF\Spatial\DBAL\Types\Geometry\PointType
What should I do more to be able to use this function in my Repository? Error, which I'm getting is:
Doctrine\ORM\Query\QueryException:
[Syntax Error] line 0, col 70: Error: Expected known function, got 'ST_DISTANCE_SPHERE'
at vendor\doctrine\orm\lib\Doctrine\ORM\Query\QueryException.php:54
Based on the error message, you may need something like:
doctrine:
dbal:
url: '%env(resolve:DATABASE_URL)%'
types:
geometry: CrEOF\Spatial\DBAL\Types\GeometryType
point: CrEOF\Spatial\DBAL\Types\Geometry\PointType
orm:
dql:
numeric_functions:
# for postgresql
stdistance: CrEOF\Spatial\ORM\Query\AST\Functions\PostgreSql\STDistance
Thanks to #Nicodemuz answer I finally find the right way:
orm:
dql:
numeric_functions:
stdistance: CrEOF\Spatial\ORM\Query\AST\Functions\Mysql\STDistance
stdistancesphere: CrEOF\Spatial\ORM\Query\AST\Functions\Mysql\STDistanceSphere
distance: CrEOF\Spatial\ORM\Query\AST\Functions\MySql\Distance
geometrytype: CrEOF\Spatial\ORM\Query\AST\Functions\MySql\GeometryType
point: CrEOF\Spatial\ORM\Query\AST\Functions\MySql\Point
The second important thing was that I had to use in my query STDistanceSphere name instead of ST_DISTANCE_SPHERE to make it work fine.
Third thing, it may be helpful for MySql users like me to see this. It looks like this function is available for MySql, but it's not merged, so you should add to package some files from here .
Related
When I go to call:
enableShorthandMethods from the file "MagicalRecord+ShorthandMethods.h"using :
#import <MagicalRecord/MagicalRecord+ShorthandMethods.h>
there is an error:
Duplicate interace definition for class MagicalRecord.
I'm getting:
duplicate interface definition for class MagicalRecord.h
MR has been added with cocoaPods.
pod 'MagicalRecord'
pod 'MagicalRecord/ShorthandMethodAliases'
I tried to follow the following guide:
https://github.com/magicalpanda/MagicalRecord/blob/master/Docs/Installing-MagicalRecord.md
To no avail.
After running
'find . -iname "MagicalRecord.h"'
There was a remaining copy of the file from the previous non-pods installation. The got rid of this very message.
Turns out it was something to do with an XCode5 project using ARC. Setting a flag for no ARC fixed the problem. An object associated with the MR was involved.
We have recipe which use node attribute:
python_pip 'request_proxy' do
virtualenv '/opt/proxy/.env'
version node.default['request-proxy']['version']
Chef::Log.info('Auth request proxy #{version}')
action :install
end
Attribute is set on node level and everything is OK, but for test purposes i want to override it in my local (kitchen/vagrant) node. As first step i add attribute to my .kitchen.yml:
suites:
- name: default
run_list:
- recipe[proxy_install]
attributes: {request-proxy: {'version': '1.0.8'}}
Unfortunately node still use the "default" version. Everything works fine, without any error and completly ignores my attributes.
Later i tried add this to parameter file (chef-client -j params.json) on production node, result was the same.
What I missed? What am I doing wrong?
P.S. Chef::Log.info('Auth request proxy #{version}') is also completely ignored ??
Can you try using YAML? kitchen.yml is not a JSON file, so I'm not sure that your JSON embedded inside it would work.
attributes:
request-proxy:
version: '1.0.8'
Also, you probably should not be using node.default, unless you want to pick up the default value only (and never any overrides). If you want to use the attribute precedence (default, normal, override, force) in Chef, you should be doing:
node['request-proxy']['version']
Finally, you also have a single-quoted string with a variable. This will never work like you expect in Ruby (are you running rubocop? It would have caught this). Try it with double quotes, and remove it from the middle of your resource:
Chef::Log.info("Auth request proxy #{version}")
I have built a custom contenttype with an image field in Bolt 2.0.
image:
type: image
If no folder is specified the uploaded file goes to a folder named by the year-month
Result: 2014-11/myFileName.jpg
With the tag upload I can change this to something else.
image:
type: image
upload: "News/"
Result: News/myFileName.jpg
Is it possible to get the year-month folders after my costom path?
Result: News/2014-11/myFileName.jpg
The answer to this is yes, but not very simply so if you want a configurable way to do this you need to wait for 2.1 of Bolt where we're going to add variables to the upload: setting.
If you don't mind setting up your own bootstrap file and modifying the application then you can do it now.
The date prefix is generated by the $app['upload.prefix'] setting and currently returns the date string. What you need to do to modify this is change this to your own closure. I haven't tested this on a project so tweak if needed but after:
$app->initialize();
// Redefine the closure
$app['upload.prefix'] = function() {
$setting = $app['request']->get('handler');
$parts = explode('://', $setting);
$prefix = rtrim($parts[0], '/') . '/';
return $prefix.date('Y-m') . '/';
};
$app->run();
What we're doing here is reading the setting which is passed in the request and then concatenating the default date prefix onto the end of it.
As mentioned earlier 2.1 will see variable support introduced into the paths so options like
upload: news/{%month%}/{%day%}
upload: uploads/{%contenttype%}/{%id%}
will be easily definable in the contenttypes.yml file so If you don't mind waiting for a couple of months then this is obviously much simpler.
As of 3.2.9 this {%id%} principle doesn't seem to work yet ... :(
I want to swap the content in answers table with ActiveRecord.
code 1:
Archieve::Answer.find_each do |answer|
str = answer.content
dosomething() #change the value
answer.update_attribute(:content,str)
end
But It doesn't change the value of content.
code 2:
Archieve::Answer.find_each do |answer|
str = answer.content
dosomething() #change the value
answer.reload
answer.update_attributes(
:content => str
)
end
Before update the :content attributes, I reload the record every time.
It can indeed change the the value.
Why?
What's the difference between code 1 & code 2?
Source Code
###1 Post Debug Message:
Updated Post:
Changed?: false
valid?: true
errors: #<ActiveModel::Errors:0xa687568>
errors: #<ActiveModel::Errors:0xa687568 #base=#<Archieve::Answer id: 9997190932758339, user_id: 4163690810052834, question_id: 3393286738785869, content: "狗狗生病，好可怜呀，", is_correct: false, votes_count: 0, comments_count: 0, created_at: "2011-11-06 18:38:53", updated_at: "2011-11-06 18:38:53">, #messages={}>
possible ActiveRecord 3.1.1 bug
The OP mentioned to me that he uses require "active_record" in a stand alone script (not using rails runner).
There is no separate Rails application for his task, he just uses a script. This is not necessarily bad, and has worked in earlier ActiveRecord versions, e.g. 2.x AFAIK -- maybe this is a regression in Rails 3.1 due to a new dependency?
# the OP's require statements:
require 'rubygems'
require 'logger'
require 'yaml'
require 'uuidtools'
require 'active_record'
complete code here: https://raw.github.com/Zhengquan/Swap_Chars/master/lib/orm.rb
maybe a dependency is missing, or problem with AR 3.1.1 when initialized stand alone?
It could be a bug actually
It could be that update_attribute() triggers a bug in the dirty-tracking of attributes, which then incorrectly assumes that the object has not changed, and as a result it will not be persisted, although the implementation of update_attribute() calls save() (see code fragment below).
I've seen something like this with an older version of Mongoid -- could be that there is a similar hidden bug in your ActiveRecord version for update_attribute()
In the Rails Console monkey-patch update_attribute like this:
class ActiveRecord::Base
def update_attribute(name, value) # make sure you use the exact code of your Rails Version here
send(name.to_s + '=', value)
puts "Changed?: #{changed?}" # this produced false in the OP's scenario
puts "valid?: #{valid?}"
puts "errors: #{errors.inspect}"
save
end
end
then try to run your Code 1 again...
you shouldn't see "Changed?: false".. if it returns false, although you changed the attribute, then there is a bug in your ActiveRecord version and you should report it.
Code 1:
NOTE: check the definition of update_attribute() (singular) here:
(please read the fine-print regarding validations -- it doesn't sound like a good idea to use that method)
http://ar.rubyonrails.org/classes/ActiveRecord/Base.html#M000400
See also:
Rails: update_attribute vs update_attributes
The source code for update_attribute() looks like this:
2260: def update_attribute(name, value)
2261: send(name.to_s + '=', value)
2262: save
2263: end
it could fail if there is a bug with the dirty-tracking of attributes...
Code 2:
The second code looks correct.
There are a couple of things to also consider:
1) which attributes did you define as accessible, via attr_accessible ?
e.g. only accessible attributes will be updated via update_attributes()
http://apidock.com/rails/ActiveRecord/Base/update_attributes
2) which validations do you use?
are you sure the validations pass for the record when you call update_attribute?
See also:
http://guides.rubyonrails.org/active_record_querying.html
http://m.onkey.org/active-record-query-interface
http://api.rubyonrails.org/classes/ActiveRecord/Base.html
How can I log all executed SQL statements to the console/stdout when using Ruby MySQL?
Like the log/development.log output from rails.
If you mean Ruby/MySQL, that provides a debug() function which performs the same function as mysql_debug() -- if your client library has been compiled with debugging, you can get DBUG to trace things for you. This might give what you're after (with a bit of clean-up.)
Another approach would be to capture the MySQL packets using tcpdump and decode them with maatkit.
A third approach would be to alias Mysql.query and Mysql.real_query with your own functions that do logging. Something like this (untested! trivial example! doesn't handle blocks!):
class Mysql
alias_method :old_query, :query
def query(sql)
$stderr.puts "SQL: #{sql}"
old_query(sql)
end
end
Rails uses ORMs like ActiveRecord which has it's logger associated to it.
I don't think MySQL gem has a logger...