Have anyone noticed something like this? Why is it happening?
ruby-1.9.2-p290 :006 > User.count
(0.4ms) SELECT COUNT(*) FROM "users"
=> 102
ruby-1.9.2-p290 :007 > User.count + 1
(0.4ms) SELECT COUNT(*) FROM "users"
=> 103
ruby-1.9.2-p290 :008 > User.count+ 1
(0.4ms) SELECT COUNT(*) FROM "users"
=> 103
ruby-1.9.2-p290 :009 > User.count+1
(0.4ms) SELECT COUNT(*) FROM "users"
=> 103
ruby-1.9.2-p290 :010 > User.count +1
(0.5ms) SELECT COUNT(1) FROM "users"
=> 102
Using ruby 1.9.2p290 (2011-07-09 revision 32553) [x86_64-linux] && Rails 3.1.3
Extra stuff:
ruby-1.9.2-p290 :007 > "ayay".length + 1
=> 5
ruby-1.9.2-p290 :008 > "ayay".length +1
ArgumentError: wrong number of arguments(1 for 0)
from (irb):8:in `length'
...
This depends on the fact that in Ruby white spaces can be significant. You see different results because Ruby interprets your example in different ways. So
The first:
"ayay".length + 1
is like
"ayay".length.+(1)
And the second:
"ayay".length +1
is like
"ayay".length(+1)
In this way you can see why Ruby gives an error in the second case.
Regarding the count problem: Ruby interprets the code as:
User.count(+1)
And, as you can see from the generated SQL, there is a difference because +1 is considered the column_name parameter.
Related
I am looking at an example of code and confused.
def self.type(input)
input.strip!
return 'question' if input[-1,1] == '?'
end
So, input[-1] makes sense, it is checking if the last character is a question mark. What does the 1 do? Also, all the example tests pass without the 1.
input[-1,1] means reading 1 character from the last character. It gives the same result as input[-1] because you are reading just 1 character from the last character.
Look at some examples to understand more:
❯ irb
2.3.0 :001 > input = 'lenin'
=> "lenin"
2.3.0 :002 > input[-1]
=> "n"
2.3.0 :003 > input[-1,1]
=> "n"
2.3.0 :004 > input[-2]
=> "i"
2.3.0 :005 > input[-2, 1]
=> "i"
2.3.0 :006 > input[-2, 2]
=> "in"
2.3.0 :007 > input[-2, 3]
=> "in"
I came across this ruby object_id allocation question sometime back and then read this awesome article which talks about VALUE and explains why object_id of true, nil and false the way they are. I have been toying with ruby2.0 object_id when I found the apparent change that has been made regarding object_id of true and nil.
forbidden:~$ ruby -v
ruby 2.0.0p0 (2013-02-24 revision 39474) [x86_64-linux]
forbidden:~$
forbidden:~$ irb
irb(main):001:0> true.object_id
=> 20
irb(main):002:0> false.object_id
=> 0
irb(main):003:0> nil.object_id
=> 8
irb(main):004:0> exit
forbidden:~$
forbidden:~$ rvm use 1.9.3
Using /home/forbidden/.rvm/gems/ruby-1.9.3-p392
forbidden:~$ ruby -v
ruby 1.9.3p392 (2013-02-22 revision 39386) [x86_64-linux]
forbidden:~$
forbidden:~$ irb
irb(main):001:0> true.object_id
=> 2
irb(main):002:0> false.object_id
=> 0
irb(main):003:0> nil.object_id
=> 4
tl;dr: The values for true and nil were respectively 2, 4 in 1.9.3 and 1.8.7, but have been changed to 20, 8 in ruby2.0.0 - even though the id of false remains the same i.e. 0 and the ids for Fixnum maintains the same old 2n+1 pattern.
Also, the way Fixnum and Bignum are implemented is still the same in 2.0.0 as the example given in the above mentioned article also runs just the same way it used to:
irb(main):001:0>
irb(main):002:0* ((2**62)).class
=> Bignum
irb(main):003:0> ((2**62)-1).class
=> Fixnum
irb(main):004:0>
What's the reason behind this object_id change?
Why was this change made? How is this going to help developers?
A look at the Ruby source where these values are defined suggests that this has something to do with “flonums” (also see the commit where this was introduced). A search for ”flonum” came up with a message on the Ruby mailing list discussing it.
This is a technique for speeding up floating point calculations on 64 bit machines by using immediate values for some floating point vales, similar to using Fixnums for integers. The pattern for Flonums is ...xxxx xx10 (i.e. the last two bits are 10, where for fixnums the last bit is 1). The object_ids of other immediate values have been changed to accomodate this change.
You can see this change by looking at the object_ids of floats in Ruby 1.9.3 and 2.0.0.
In 1.9.3 different floats with the same value are different objects:
1.9.3p385 :001 > s = 10.234
=> 10.234
1.9.3p385 :002 > t = 10.234
=> 10.234
1.9.3p385 :003 > s.object_id
=> 2160496240
1.9.3p385 :004 > t.object_id
=> 2160508080
In 2.0.0 they are the same:
2.0.0p0 :001 > s = 10.234
=> 10.234
2.0.0p0 :002 > t = 10.234
=> 10.234
2.0.0p0 :003 > s.object_id
=> 82118635605473626
2.0.0p0 :004 > t.object_id
=> 82118635605473626
I am trying to use the prepared statements in ruby with pg gem. This is how my statement looks like
conn.prepare("insert_values", "insert into " + objectName + "(" + headerStr + ") values (" + prep_values + ")")
conn.exec_prepared("insert_values", arr)
I keep getting the error
Prepared Statement insert_values already exists.
How Do i Fix this?? Thanks
Try to run:
conn.exec("DEALLOCATE name_of_prepared_statement")
In your example:
conn.exec("DEALLOCATE insert_values")
Simple test and it is working in my irb:
1.8.7 :001 > require 'rubygems'
=> true
1.8.7 :002 > require 'pg'
=> true
1.8.7 :003 > conn = PGconn.connect(:host => 'localhost', :port => 5912, :user => 'test', :dbname => 'test' )
=> #<PGconn:0x7fe6ac703970>
1.8.7 :005 > conn.prepare("insert_values", "select * from data where id < $1")
=> #<PGresult:0x7fe6ac6b2e58>
1.8.7 :006 > conn.prepare("insert_values", "select * from data where id < $1 and id > $2")
PGError: ERROR: prepared statement "insert_values" already exists
from (irb):6:in 'prepare'
from (irb):6
1.8.7 :007 > conn.prepare("insert_values", "select * from data where id < $1")
PGError: ERROR: prepared statement "insert_values" already exists
from (irb):7:in 'prepare'
from (irb):7
1.8.7 :008 > conn.exec("DEALLOCATE insert_values")
=> #<PGresult:0x7fe6ac6738c0>
1.8.7 :009 > conn.prepare("insert_values", "select * from data where id < $1")
=> #<PGresult:0x7fe6ac665fe0>
1.8.7 :010 > conn.exec_prepared("insert_values",[200])
=> #<PGresult:0x7fe6ac65d188>
1.8.7 :011 > conn.exec("DEALLOCATE insert_values")
=> #<PGresult:0x7fe6ac654df8>
1.8.7 :012 > conn.exec_prepared("insert_values",[200])
PGError: ERROR: prepared statement "insert_values" does not exist
from (irb):12:in 'exec_prepared'
from (irb):12
This is a better way reusing prepare(), avoid prepared statement "my_statement" already exists:
sql = "select * from my_table where id = $1"
begin
ActiveRecord::Base.connection.raw_connection.prepare('my_statement', sql)
rescue PG::DuplicatePstatement => e
end
pg_result = ActiveRecord::Base.connection.raw_connection.exec_prepared('my_statement', [my_table_id])
I have a variable. When I do puts var_name I get this hash:
"{\"numConnections\": 163}"
But when I try to get that number 163 from the value numConnections it isn't working. Here is what I am trying:
connections = temp_var["\"numConnections\""]
puts connections.inspect
or:
connections = temp_var["numConnections"]
puts connections.inspect
both of which equally don't work.
Any idea how to extract that 163 from there?
If you have a JSON string, you need to parse it into a hash before you can use it to access its keys and values in a hash-like way. Consider this IRB session:
1.9.3p194 :001 > require 'json'
=> true
1.9.3p194 :002 > temp_var = "{\"numConnections\": 163}"
=> "{"numConnections": 163}"
1.9.3p194 :003 > temp_var.class
=> String
1.9.3p194 :004 > JSON.parse(temp_var)
=> {"numConnections"=>163}
1.9.3p194 :005 > JSON.parse(temp_var)['numConnections']
=> 163
Can someone explain what's happening here?
It seems that the placeholding syntax in SQL statement string doesn't work as expected (or, to say it in a different way, it violates the principle of least surprise), and during runtime an unexpected substitution/escaping is done for var2:
ruby-1.9.2-p290 :001 > puts RUBY_VERSION
1.9.2
=> nil
ruby-1.9.2-p290 :002 > require 'ipaddr'
=> true
ruby-1.9.2-p290 :003 > require 'sqlite3'
=> true
ruby-1.9.2-p290 :004 > var1 = Addrinfo.ip("1.2.3.4")
=> #<Addrinfo: 1.2.3.4>
ruby-1.9.2-p290 :005 > var2 = var1.ip_address
=> "1.2.3.4"
ruby-1.9.2-p290 :006 > var3 = "1.2.3.4"
=> "1.2.3.4"
ruby-1.9.2-p290 :007 > var2 == var3
=> true
ruby-1.9.2-p290 :008 > var2 === var3
=> true
ruby-1.9.2-p290 :009 > var2.eql?(var3)
=> true
ruby-1.9.2-p290 :010 > db = SQLite3::Database.open( "test.db" )
=> #<SQLite3::Database:0x00000100bcfce0>
ruby-1.9.2-p290 :011 > db.execute( "SELECT * FROM devices WHERE deviceaddr=?", var2 )
=> []
ruby-1.9.2-p290 :011 > db.execute( "SELECT * FROM devices WHERE deviceaddr=?", var2.to_s )
=> []
ruby-1.9.2-p290 :012 > db.execute( "SELECT * FROM devices WHERE deviceaddr=?", var3 )
=> [["TEST_DEVICE", "1.2.3.4"]]
Without the SQL placeholder it works (but exposes the db to SQL injections!):
ruby-1.9.2-p290 :013 > db.execute( "SELECT * FROM devices WHERE deviceaddr='#{var2}'" )
=> [["TEST_DEVICE", "1.2.3.4"]]
So what is a safe way to make this work?
TL;DR: SQLite uses UTF; convert Addrinfo's 8-bit ASCII output.
One "safe" way is to use force_encoding("UTF-8") on the output from Addrinfo, so:
> var1.ip_address.encoding
=> #<Encoding:ASCII-8BIT>
> var3.encoding
=> #<Encoding:UTF-8>
> db.execute("SELECT * FROM foo WHERE ip=?", var2.force_encoding("UTF-8"))
=> [["1.2.3.4"]]