I must be missing something here, but when I try to get highlighting on a search with Elasticsearch, I'm not seeing any highlighting at all, but no errors either. I don't think it's a Tire issue, but I mention Tire just in case it's important. The indexing using Tire is pretty simple (some fields taken out for brevity):
mapping :_source => { :excludes => ['attachment'] } do
indexes :id, :type => 'integer'
indexes :title, :store => true
indexes :attachment, :type => 'attachment', :_source => { :enabled => false }
end
Using curl, I can try this query, which works fine but there's no highlighting in the results:
curl -XPOST http://localhost:9200/myobject/_search\?pretty\=true -d '{
"query": {"query_string": {"query": "foobar"}},
"highlight": {"fields": {"Title":{}}}
}'
Note that I added the ":store => true" in the mapping just to make sure, though I don't think it should be necessary to make highlighting work. So I'm guessing I'm missing something either in the mapping or in the query specification, but I'm not seeing it. Any suggestions would be very much appreciated. Thanks.
Field names are case-sensitive in elasticsearch. Title and title are two different fields. Try this query:
curl -XPOST http://localhost:9200/myobject/_search\?pretty\=true -d '{
"query": {"query_string": {"query": "foobar"}},
"highlight": {"fields": {"title":{}}}
}
Related
I wonder if someone can help me with my conf file problem. I need to get the output like below but I get problems in using the inifile. I have put below my code and testing output. My service won't start because of the '[]'. Your comments and ideas are highly appreciated. Thanks!
Expected output
cat /etc/service.conf
info something something...
without section header
setting1=value1
Testings
testscript1.pp
ini_setting {'setx':
ensure => present,
path => '/etc/service.conf',
key_val_separator => '=',
setting => 'setting1',
value => 'value1',
}
output of testscript1.pp
cat /etc/service.conf
info something something...
[setx]
setting1=value1
testscript2.pp
$defaults = {
ensure => present,
path => '/etc/service.conf',
key_val_separator => '=',
}
$settings = {
' ' => {
'setting1' => 'value1',
}
}
create_ini_settings($settings,$defaults)
output of testscript2.pp
cat /etc/service.conf
info something something...
[ ]
setting1=value1
Since I really wanted to delete the [] character because it's causing error during service restart, I used section_prefix => '#',. The first puppet agent run is smooth and working. Problem now is if puppet agent runs on its frequency time (like let's say every hour), it will auto-append details in conf file due to lack of section header. I decided to use ini_subsetting but I'm getting errors with it.
testscript3.pp
ini_subsetting {'subset':
ensure => present,
section => '',
key_val_separator => '=',
path => '/etc/service.conf',
setting => 'setting1',
subsetting => '',
value => 'value1',
}
output of testscript3.pp
Error: Failed to apply catalog: Parameter path failed on Ini_subsetting[subset]: File paths must be fully qualified, not '/etc/service.conf'.
Any suggestions or advises are highly appreciated.
Thank you.
If the file you are managing does not have section markers of some kind, then it is not an INI file, not even in the generalized sense that the puppetlabs/inifile module supports. To the best of my knowledge, you'll need to choose a different approach to managing the file.
You could consider templating the whole file, or writing a custom type and provider for it, but before going to so much trouble, you should consider whether a good old file_line resource from puppetlabs/stdlib would be adequate for your needs.
Have you tried your testscript1.pp with section => ''?
It would look like this:
ini_setting {'setx':
ensure => present,
path => '/etc/service.conf',
key_val_separator => '=',
section => '',
setting => 'setting1',
value => 'value1',
}
And the output would be:
cat /etc/service.conf
info something something...
setting1=value1
Or you could try to use force_new_section_creation => false, as it is true by default and forces the creation of a section, as stated in the module’s reference.
As for your 3rd example, it probably fails because of the blank subsetting parameter. The ini_subsetting resource type requires both setting and subsetting parameters to work.
In my rspec test, I defined the following array of hashes and performed a POST:
body = {:event => { :invitations_attributes =>
[ {:recipient_id => 40}, {:email => 'a#a.com'}, {:facebook_id => 123456789} ] } }
post "#{#url}.json", body.reverse_merge(:auth_token => #token)
Based on the above, I expected the Rails server to receive "invitations_attributes" as an array of hashes. However, the developer.log file has the following:
Parameters: {"auth_token"=>"RSySKfN2L8b5QPqnfGf7", "event"=>{"invitations_attributes"=>
[{"recipient_id"=>"40", "email"=>"a#a.com", "facebook_id"=>"123456789"}]}}
(In the parameters above, "invitation_attributes" array contains only 1 hash.)
The following curl statement:
curl -X POST -H "Content-type: application/json" http://localhost:3000/api/v1/events.json -d '{"auth_token":"RSySKfN2L8b5QPqnfGf7","event":{"invitation_attributes":[{"recipient_id":40},{"email":"a#a.com"},{"facebook_id":123456789}]}}'
results in Rails' receiving the array of hashes intact, as evidenced by the log file entry below.
Parameters: {"auth_token"=>"RSySKfN2L8b5QPqnfGf7", "event"=>{"invitation_attributes"=>
[{"recipient_id"=>40}, {"email"=>"a#a.com"}, {"facebook_id"=>123456789}]}}
Rack/test is exhibiting this behavior for PUT operations as well as POST.
Why is rack/test combining the 3 hashes into 1 rather than sending the array exactly as it is defined? Is there a setting which will cause rack to exhibit the behavior I expected?
One workaround is to ensure that each hash contains each key by inserting nil value placeholder keys as follows:
body = {:event => { :invitations_attributes => [
{:recipient_id => 40, :recipient_email => nil, :recipient_facebook_id => nil},
{:recipient_email => user.email, :recipient_id => nil, :recipient_facebook_id => nil},
{:recipient_facebook_id => new_unused_facebook_id, :recipient_email => nil, :recipient_id => nil} ] } }
The hash above does cause the server to receive 3 separate hashes within the array. However, inserting placeholder keys is inconvenient and should not be required. Furthermore, scenarios where a controller acts differently based on the presence of a such a key (albeit uncommon), cannot be tested.
I got some trouble ordering resources from a module.
class { 'postgres' :
charset => 'UTF8',
locale => 'fr_FR',
require => Service['postgresqld'],
}->
class { 'postgresql::server':
}
postgresql::role { 'role1' :
namevar => 'redmine',
password_hash => 'random_md5',
createdb => true,
require => Class['postgres'],
}
postgresql::database_user {'charly':
password => 'random',
role => 'redmine',
require => postgresql::role['role1'],
}
I want to order this, but it appears to have a syntax error on the last line at role.
I'm pretty sure it comes from the capitalized first letter. But Puppet doesn't want to run the manifest if I put a capital letter Postgresql::role['role1] or postgresql::Role['role1]. Without capital letter, I "just" get a warning :
warning: Deprecation notice: Resource references should now be capitalized on line 61 in file /home/charly/testManifests/part1.pp
I'm doing something wrong, but I don't know what. I searched for an answer on the Internet but can't find what I want neither in tutorials nor on the forums.
Try using chaining arrows to your resource group references e.g.
Class['postgres'] -> Class['postgresql::server']
class { 'postgres' :
charset => 'UTF8',
locale => 'fr_FR',
require => Service['postgresqld']
}
class { 'postgresql::server': }
More detail can be found here in the puppet reference Chaining Arrows
I have a post method that accepts JSON:
post '/channel/create' do
content_type :json
#data = JSON.parse(env['rack.input'].gets)
if #data.nil? or !#data.has_key?('api_key')
status 400
body({ :error => "JSON corrupt" }.to_json)
else
status 200
body({ :error => "Channel created" }.to_json)
end
As a newbie to rspec I am bewildered trying to figure out how to write a test against that POST with an acceptable JSON payload. The closest I got to is this which is woefully inaccurate but I don't seem to be asking the Google god the right questions to help me out here.
it "accepts create channel" do
h = {'Content-Type' => 'application/json'}
body = { :key => "abcdef" }.to_json
post '/channel/create', body, h
last_response.should be_ok
end
Any best practice guidance for testing APIs in Sinatra will be most appreciated also.
The code you've used is fine, although I would structure it slightly differently as I don't like to use it blocks the way you normally see them, I think it encourages testing of more than one aspect of a system at a time:
let(:body) { { :key => "abcdef" }.to_json }
before do
post '/channel/create', body, {'CONTENT_TYPE' => 'application/json'}
end
subject { last_response }
it { should be_ok }
I've used let because it's better than an instance variable in a before block (kudos to you for not doing that). The post is in a before block because it's not really part of the spec, but a side effect that occurs prior to what you're speccing. The subject is the response and that makes the it a simple call.
Because checking the response is ok is needed so often I put it in a shared example:
shared_examples_for "Any route" do
subject { last_response }
it { should be_ok }
end
and then call it as such:
describe "Creating a new channel" do
let(:body) { { :key => "abcdef" }.to_json }
before do
post '/channel/create', body, {'CONTENT_TYPE' => 'application/json'}
end
it_should_behave_like "Any route"
# now spec some other, more complicated stuff…
subject { JSON.parse(last_response.body) }
it { should == "" }
and because the content type changes so often, I put that in a helper:
module Helpers
def env( *methods )
methods.each_with_object({}) do |meth, obj|
obj.merge! __send__(meth)
end
end
def accepts_html
{"HTTP_ACCEPT" => "text/html" }
end
def accepts_json
{"HTTP_ACCEPT" => "application/json" }
end
def via_xhr
{"HTTP_X_REQUESTED_WITH" => "XMLHttpRequest"}
end
It's easy to add this in where it's needed by including it via the RSpec config:
RSpec.configure do |config|
config.include Helpers, :type => :request
then:
describe "Creating a new channel", :type => :request do
let(:body) { { :key => "abcdef" }.to_json }
before do
post '/channel/create', body, env(:accepts_json)
end
Having said all that, personally, I wouldn't post using JSON. HTTP POST is simple to handle, and every form and javascript library does it easily and well. Respond with JSON by all means, but don't post JSON, HTTP is a lot easier.
Edit: after writing out the Helpers bit above I realised it would be more helpful as a gem.
Looks like the ability to do post :update, '{"some": "json"}' was added to the internal ActionPack test_case.rb used by rspec in this commit:
https://github.com/rails/rails/commit/5b9708840f4cc1d5414c64be43c5fc6b51d4ecbf
Since you're using Sinatra I'm not sure the best way to get those changes—you might be able to upgrade ActionPack directly, or patch from the above commit.
If you want to look at last_response as JSON, you could try rack-test-json which makes this trivial:
expect(last_response).to be_json
expect(last_response.as_json['key']).to be == 'value'
Using paypal-recurring gem, how can we ask for full refunds for a recurring profile? I'm using Ruby on Rails for developing my application. I tried searching for it, but didn't found appropriate answer to my problem.
I've found this link:
https://www.x.com/developers/paypal/documentation-tools/api/refundtransaction-api-operation-soap
But I don't understand how to integrate it with my app.
I'm using this gem,
https://github.com/fnando/paypal-recurring
And my code is as follows:
def refund_full_paypal_transaction
PayPal::Recurring.new({
:profile_id => "customers profile id",
:transaction_id => "to_be_refunded transaction_id",
:reference => "12345",
:refund_type => :full,
:amount => "whatever amount",
:currency => "USD"
})
end
It looks like the gem already provides RefundTransaction for you. I'm not a Ruby developer, but if you look at /lib/paypal/recurring/request.rb you'll see it's a simple class that builds your API requests for you.
The METHODS array at the top specifies the different requests that it seems to support, and RefundTransaction is one of them.
So again, I can't give too detailed an answer without knowing Ruby better, but from what I see you can simply pass in the refund attribute there along with the original transaction ID to be refunded and it'll handle the rest for you.
Hope that helps.
# Request a refund.
ppr = PayPal::Recurring.new({
:profile_id => "I-VCEL6TRG35CU",
:transaction_id => "ABCEDFGH",
:reference => "1234",
:refund_type => :partial,
:amount => "9.00",
:currency => "USD"
})
response = ppr.refund
worked !!! found in https://github.com/fnando/paypal-recurring/blob/master/lib/paypal/recurring/base.rb
Thanks !!!