Forum: Ruby on Rails Weird assignment problem, very confused :(

9a1b1136b42f179b246b9d3eb66fc996?d=identicon&s=25 Christoph B. (christoph_b)
on 2011-08-29 18:06
(Received via mailing list)
Hey, I have the following line in my controller:

User.create(:email => "fuuu@bar.com", :password =>
'asldfkjadsfadsf', :ip => request.remote_ip)

my IP is 127.0.0.1 - now User.find_by_ip('127.0.0.1') returns 0
records although User.first contains '127.0.0.1'

if I change it to:

User.create(:email => "fuuu@bar.com", :password =>
'asldfkjadsfadsf', :ip => '127.0.0.1')
the finder returns the record

The model is a devise model, ip is attr_accessible
Can anyone please help me getting out of this confusion? I don't
understand it
9a1b1136b42f179b246b9d3eb66fc996?d=identicon&s=25 Christoph B. (christoph_b)
on 2011-08-29 19:36
(Received via mailing list)
This is really weird, either a bug (it's 3.1 rc5) or I don't know:

1) DocType.create(:name => request.remote_ip)
  DocType.find_by_name('127.0.0.1')
  DocType Load (1.4ms)  SELECT "doc_types".* FROM "doc_types" WHERE
"doc_types"."name" = '127.0.0.1' LIMIT 1
 => nil



DocType.create(:name => "127.0.0.1")
  DocType.find_by_name('127.0.0.1')
  DocType Load (1.4ms)  SELECT "doc_types".* FROM "doc_types" WHERE
"doc_types"."name" = '127.0.0.1' LIMIT 1
 => #<DocType id: 3, name: "127.0.0.1", description: nil>
81b61875e41eaa58887543635d556fca?d=identicon&s=25 Frederick Cheung (Guest)
on 2011-08-29 20:04
(Received via mailing list)
On Aug 29, 6:34pm, sol <ch.bl...@gmail.com> wrote:
> This is really weird, either a bug (it's 3.1 rc5) or I don't know:
>
> 1) DocType.create(:name => request.remote_ip)
>  DocType.find_by_name('127.0.0.1')
>  DocType Load (1.4ms) SELECT "doc_types".* FROM "doc_types" WHERE
> "doc_types"."name" = '127.0.0.1' LIMIT 1
> => nil
>
So what's actually in the database in that case? Any unexpected
characters (new lines etc.) ?

Fred
63c72161fba6e27cb05c078651c5e969?d=identicon&s=25 Alexey Muranov (alexey_m)
on 2011-08-29 20:06
What does `User.first.ip.inspect` return in the two cases?
9a1b1136b42f179b246b9d3eb66fc996?d=identicon&s=25 Christoph B. (christoph_b)
on 2011-08-29 23:10
(Received via mailing list)
how can I get more details about the encoding/chars in the dbconsole?

sqlite> select name from doc_types;
127.0.0.1
127.0.0.1


On 29 Aug., 20:02, Frederick Cheung <frederick.che...@gmail.com>
9a1b1136b42f179b246b9d3eb66fc996?d=identicon&s=25 Christoph B. (christoph_b)
on 2011-08-29 23:14
(Received via mailing list)
inspect returns:

ruby-1.9.2-p180 :009 > DocType.all.map {|d| d.name.inspect}
  DocType Load (1.4ms)  SELECT "doc_types".* FROM "doc_types"
 => ["\"127.0.0.1\"", "\"127.0.0.1\""]

and as above find only returns on of them (the one using
request.remote_ip
96146b7a23174e2e024c06a49f845bb8?d=identicon&s=25 Jeffrey L. Taylor (Guest)
on 2011-08-29 23:14
(Received via mailing list)
Quoting sol <ch.blank@gmail.com>:
> This is really weird, either a bug (it's 3.1 rc5) or I don't know:
>
> 1) DocType.create(:name => request.remote_ip)
>   DocType.find_by_name('127.0.0.1')
>   DocType Load (1.4ms)  SELECT "doc_types".* FROM "doc_types" WHERE
> "doc_types"."name" = '127.0.0.1' LIMIT 1
>  => nil
>

Dynamic typing is wonderful, until it isn't.  My hypothesis is that
remote_ip
is not a Fixnum or Bignum but a custom class that overrides to_s.  To
test the
hypothesis, I'd run the following in the console of writing to the log.

puts request.remote_ip.class
puts request.remote_ip
puts request.remote_ip.to_s
puts "#{request.remote_ip}"
puts request.remote_ip.inspect

DocType.create(:name => request.remote_ip)
DocType.last
DocType.create(:name => request.remote_ip.to_s)
DocType.last

Somewhere in this, I expect the truth will be revealed.

A IPv4 address is a 32 bit, unsigned number.  It is usually
represented/rendered in dotted quad notation, but 0x7F000001 or
2130706433 are
equally valid representations of the local or loopback interface's IPv4
address.

HTH,
  Jeffrey
9a1b1136b42f179b246b9d3eb66fc996?d=identicon&s=25 Christoph B. (christoph_b)
on 2011-08-29 23:40
(Received via mailing list)
the output for the above lines is:

String
127.0.0.1 (.ip)
127.0.0.1 (.ip.to_s)
127.0.0.1 "#{d.ip}"
"127.0.0.1" ip.inspect

no idea what this could be else... the size is 9 in all examples
54404bcac0f45bf1c8e8b827cd9bb709?d=identicon&s=25 7stud -- (7stud)
on 2011-08-30 00:44
Christoph B. wrote in post #1019055:
> Hey, I have the following line in my controller:
>
> User.create(:email => "fuuu@bar.com", :password =>
> 'asldfkjadsfadsf', :ip => request.remote_ip)
>
> now User.find_by_ip('127.0.0.1') returns 0
> records
>
> if I change it to:
>
> User.create(:email => "fuuu@bar.com", :password =>
> 'asldfkjadsfadsf', :ip => '127.0.0.1')
> the finder returns the record
>

That seems like definitive proof that:

request.remote_ip != '127.0.0.1'

In fact you could test that:

if request.remote_ip == '127.0.0.1'
  puts 'yes'
else
  puts 'no'
end


> inspect returns:
>
> ruby-1.9.2-p180 :009 > DocType.all.map {|d| d.name.inspect}
>   DocType Load (1.4ms)  SELECT "doc_types".* FROM "doc_types"
>  => ["\"127.0.0.1\"", "\"127.0.0.1\""]
>

The output shows that the string is actually "127.0.0.1"--not 127.0.0.1.
For example:

data = [
  %q{"127.0.0.1"},
  %q{127.0.0.1}
]

data.each do |str|
  p str
end

--output:--
"\"127.0.0.1\""
"127.0.0.1"

See the difference?
63c72161fba6e27cb05c078651c5e969?d=identicon&s=25 Alexey Muranov (alexey_m)
on 2011-08-30 09:04
7stud -- wrote in post #1019114:

>
>> inspect returns:
>>
>> ruby-1.9.2-p180 :009 > DocType.all.map {|d| d.name.inspect}
>>   DocType Load (1.4ms)  SELECT "doc_types".* FROM "doc_types"
>>  => ["\"127.0.0.1\"", "\"127.0.0.1\""]
>>
>
> The output shows that the string is actually "127.0.0.1"--not 127.0.0.1.


I disagree, this output shows only that the `inspect` of the string is
(unquoted) "127.0.0.1", but the string itself is (unquoted) 127.0.0.1.
So this does not clarify the issue.

Alexey.
63c72161fba6e27cb05c078651c5e969?d=identicon&s=25 Alexey Muranov (alexey_m)
on 2011-08-30 09:17
I am sorry, Christoph, but from your post it is not clear, how you
create a record with :ip => request.remote_ip

You probably cannot do this in console (request.remote_ip not defined),
so you'll have to test it all in controller.

Can you do it in 3 steps:
1. create two records in the database (with a string and with
request.remote_ip ),
2. see what is in the database (there is, for example, a firefox
extension to browse an sqlite database),
3. verify in console that the records look identical, but find_by_ip
returns only one?

This is what i would do.

Alexey.
9a1b1136b42f179b246b9d3eb66fc996?d=identicon&s=25 Christoph B. (christoph_b)
on 2011-08-30 10:10
(Received via mailing list)
I found out with sqlite's 'dump' why it does not work, here is the
full thing:

https://gist.github.com/9fa01f6d150c3be6bd04

it seems its in a different representation, now I am not sure if this
is a rails bug or what to do with it
63c72161fba6e27cb05c078651c5e969?d=identicon&s=25 Alexey Muranov (alexey_m)
on 2011-08-30 10:29
This is strange, given that `request.remote_ip.class` returns String.
What if you use `request.remote_ip.to_s` instead of
`request.remote_ip` everywhere?

If this does not fix it, than it looks like a bug to me.

I also have an application where i store IP addresses, but i didn't try
yet to find by ip, and the IP returned by `request.remote_ip` looked
like a string to me.
I would be interested to understand what's the difference.
63c72161fba6e27cb05c078651c5e969?d=identicon&s=25 Alexey Muranov (alexey_m)
on 2011-08-30 10:41
Christophe,
I have just tested my application: i use `request.remote_ip`, and
`find_by_ip('127.0.0.1')` works for me.
If you describe a minimal example how to reproduce your problem, i can
try to test it.

I use rails 3.1rc6 and ruby 1.9.2

Alexey.
9a1b1136b42f179b246b9d3eb66fc996?d=identicon&s=25 Christoph B. (christoph_b)
on 2011-08-30 11:01
(Received via mailing list)
Thanks a lot for the efforts!

The example should be in the gist I posted above, thats exactly what I
am doing
However, which database are you using? It is sqlite for me, and I
think it might be the sqlite driver
63c72161fba6e27cb05c078651c5e969?d=identicon&s=25 Alexey Muranov (alexey_m)
on 2011-08-30 11:06
I also use sqlite in development, this is from my Gemfile:

  group :development do
    gem 'sqlite3'
  end
81b61875e41eaa58887543635d556fca?d=identicon&s=25 Frederick Cheung (Guest)
on 2011-08-30 11:44
(Received via mailing list)
On Aug 30, 9:07am, sol <ch.bl...@gmail.com> wrote:
> I found out with sqlite's 'dump' why it does not work, here is the
> full thing:
>
> https://gist.github.com/9fa01f6d150c3be6bd04
>
> it seems its in a different representation, now I am not sure if this
> is a rails bug or what to do with it
>
That byte sequence is in fact exactly the same as 127.0.0.1 (if you
encoding is ascii or anything that agrees with ascii for the lower 7
bits). For me this points at an encoding problem, but I'm not sure why
this would happen. You might try sticking some breakpoints in the
active record code to see what the difference is (or check if the ruby
encoding of the two strings you have differ)

Fred
63c72161fba6e27cb05c078651c5e969?d=identicon&s=25 Alexey Muranov (alexey_m)
on 2011-08-30 11:49
I confirm that there is a problem.
This is with Rails 3.1.0rc8

$ rails new test_ip
$ cd test_ip
$ rails generate model MyModel ip:string description:string
$ rake db:migrate
$ rails generate controller Writer write_records

app/controllers/writer_controller.rb:

class WriterController < ApplicationController
  def write_records
    MyModel.create!(:ip => request.remote_ip, :description => 'request')
    MyModel.create!(:ip => '127.0.0.1', :description => 'string')
  end
end

$ rails s

go to
http://localhost:3000/writer/write_records

$ rails c

> MyModel.all
  MyModel Load (0.2ms)  SELECT "my_models".* FROM "my_models"
 => [#<MyModel id: 1, ip: "127.0.0.1", description: "request",
created_at: "2011-08-30 09:42:09", updated_at: "2011-08-30 09:42:09">,
#<MyModel id: 2, ip: "127.0.0.1", description: "string", created_at:
"2011-08-30 09:42:09", updated_at: "2011-08-30 09:42:09">]

> MyModel.where(:ip => '127.0.0.1').all
  MyModel Load (0.2ms)  SELECT "my_models".* FROM "my_models" WHERE
"my_models"."ip" = '127.0.0.1'
 => [#<MyModel id: 2, ip: "127.0.0.1", description: "string",
created_at: "2011-08-30 09:42:09", updated_at: "2011-08-30 09:42:09">]

> MyModel.first.ip == '127.0.0.1'
  MyModel Load (0.2ms)  SELECT "my_models".* FROM "my_models" LIMIT 1
 => true

In the database for the first ip i have: X'3132372E302E302E31'
9a1b1136b42f179b246b9d3eb66fc996?d=identicon&s=25 Christoph B. (christoph_b)
on 2011-08-30 11:57
(Received via mailing list)
Thanks a lot Alexey, very helpful!

I've opened a bug but I'm not sure if it is rails or sqlite3 related:

https://github.com/rails/rails/issues/2743
so I also opened it in sqlite3:
https://github.com/luislavena/sqlite3-ruby/issues/48
54404bcac0f45bf1c8e8b827cd9bb709?d=identicon&s=25 7stud -- (7stud)
on 2011-08-30 11:58
Alexey Muranov wrote in post #1019158:
> 7stud -- wrote in post #1019114:
>
>>
>>> inspect returns:
>>>
>>> ruby-1.9.2-p180 :009 > DocType.all.map {|d| d.name.inspect}
>>>   DocType Load (1.4ms)  SELECT "doc_types".* FROM "doc_types"
>>>  => ["\"127.0.0.1\"", "\"127.0.0.1\""]
>>>
>>
>> The output shows that the string is actually "127.0.0.1"--not 127.0.0.1.
>
>
> I disagree,

Okay, I agree with your disagree.  I have no idea what this means,
though:

> this output shows only that the `inspect` of the string is
> (unquoted) "127.0.0.1", but the string itself is (unquoted) 127.0.0.1.
> So this does not clarify the issue.
>
> Alexey.


strings = [
  "abc",
  %q("abc")
]

results = strings.map do |str|
  str.inspect
end

p results

results.each do |str|
  puts str
end


--output:--
["\"abc\"", "\"\\\"abc\\\"\""]
"abc"
"\"abc\""

The second element in the array is hard to interpret: if you strip away
what inspect added to the first string, you get:

\\\"abc\\\"

I guess \\ is a literal slash and \' is an escaped quote.
63c72161fba6e27cb05c078651c5e969?d=identicon&s=25 Alexey Muranov (alexey_m)
on 2011-08-30 12:08
@Christoph, i'll look at it late again if i have time: i still do not
understand what is the difference between this and my application, and
in my application it stores `request.remote_ip` as a normal string.
Maybe as a temporary workaround you can try to parse or convert
`request.remote_ip` back and forth between some formats a few times to
get it to be a normal string.

Alexey.
54404bcac0f45bf1c8e8b827cd9bb709?d=identicon&s=25 7stud -- (7stud)
on 2011-08-30 12:13
Alexey Muranov wrote in post #1019177:
> I confirm that there is a problem.
> This is with Rails 3.1.0rc8
>
> $ rails new test_ip
> $ cd test_ip
> $ rails generate model MyModel ip:string description:string
> $ rake db:migrate
> $ rails generate controller Writer write_records
>
> app/controllers/writer_controller.rb:
>
> class WriterController < ApplicationController
>   def write_records
>     MyModel.create!(:ip => request.remote_ip, :description => 'request')
>     MyModel.create!(:ip => '127.0.0.1', :description => 'string')
>   end
> end
>
> $ rails s
>
> go to
> http://localhost:3000/writer/write_records
>
> $ rails c
>
>> MyModel.all
>   MyModel Load (0.2ms)  SELECT "my_models".* FROM "my_models"
>  => [#<MyModel id: 1, ip: "127.0.0.1", description: "request",
> created_at: "2011-08-30 09:42:09", updated_at: "2011-08-30 09:42:09">,
> #<MyModel id: 2, ip: "127.0.0.1", description: "string", created_at:
> "2011-08-30 09:42:09", updated_at: "2011-08-30 09:42:09">]
>
>> MyModel.where(:ip => '127.0.0.1').all
>   MyModel Load (0.2ms)  SELECT "my_models".* FROM "my_models" WHERE
> "my_models"."ip" = '127.0.0.1'
>  => [#<MyModel id: 2, ip: "127.0.0.1", description: "string",
> created_at: "2011-08-30 09:42:09", updated_at: "2011-08-30 09:42:09">]
>
>> MyModel.first.ip == '127.0.0.1'
>   MyModel Load (0.2ms)  SELECT "my_models".* FROM "my_models" LIMIT 1
>  => true
>
> In the database for the first ip i have: X'3132372E302E302E31'

Yes, Christoph linked to his sqlite dump, which showed the same thing::

# dump shows:
sqlite> .dump doc_types
PRAGMA foreign_keys=OFF;
BEGIN TRANSACTION;
CREATE TABLE "doc_types" ("id" INTEGER PRIMARY KEY AUTOINCREMENT NOT
NULL, "name" varchar(255), "description" varchar(255));
INSERT INTO "doc_types" VALUES(6,X'3132372E302E302E31','request');
INSERT INTO "doc_types" VALUES(7,'127.0.0.1','string');

It sure seems like an encoding issue.

Also if you read the sqlite docs,
labeling a column as a certain type is not very rigid: you can insert
different types in a column.  In fact, the sqlite2 docs say that having
typed columns is a "misfeature" of other databases.

sqlite3 docs:
===
SQLite supports the concept of "type affinity" on columns. The type
affinity of a column is the recommended type for data stored in that
column. The important idea here is that the type is recommended, not
required. Any column can still store any type of data. It is just that
some columns, given the choice, will prefer to use one storage class
over another. The preferred storage class for a column is called its
"affinity".
===

In any case, just because the column type is varchar(255)
does not mean the data stored in the column has the same type--much less
the same encoding.
63c72161fba6e27cb05c078651c5e969?d=identicon&s=25 Alexey Muranov (alexey_m)
on 2011-08-30 12:32
This is a weird issue!
@7stud, you should agree this is bug.
I have found out the difference between my application and this one.

In the controller, instead of

    MyModel.create!(:ip => request.remote_ip, :description => 'request')

do

    model = MyModel.new
    model.save  # this is important!
    model.ip = request.remote_ip
    model.description = 'request'
    model.save

then it works.

Alexey.
54404bcac0f45bf1c8e8b827cd9bb709?d=identicon&s=25 7stud -- (7stud)
on 2011-08-30 12:45
The encoding of the ip address as returned by remote_ip() is ASCII-8BIT,
and the encoding of the string literal '127.0.0.1' in rails 3.0.9 is
US-ASCII.   You can demonstrate that by putting this in an action:

    @remote_ip = request.remote_ip
    @remote_ip_encoding = @remote_ip.encoding.name
    @str_literal_encoding = '127.0.0.1'.encoding.name

and then displaying the variables in a view.  ASCII-8BIT is a synonym
for 'binary', i.e. unknown encoding.  However, I can't pin down how that
affects things because:

str = 'abc'
str2 = 'abc'
puts str.encoding.name
str.force_encoding('ASCII-8BIT')
puts str.encoding.name

if str2 == str
  puts 'yes'
else
  puts 'no'
end

--output:--
US-ASCII
ASCII-8BIT
yes
54404bcac0f45bf1c8e8b827cd9bb709?d=identicon&s=25 7stud -- (7stud)
on 2011-08-30 13:45
7stud -- wrote in post #1019185:
> However, I can't pin down how that
> affects things because:

Actually, I don't think it has anything to do with ruby--rather it's how
sqlite3 compares the search string to the two strings in the sqlite3 db.
54404bcac0f45bf1c8e8b827cd9bb709?d=identicon&s=25 7stud -- (7stud)
on 2011-08-30 13:52
Alexey Muranov wrote in post #1019182:
> This is a weird issue!
> @7stud, you should agree this is bug.
>

I don't know enough about rails to determine that.  Encoding issues are
tricky.

>
> I have found out the difference between my application and this one.
>
> In the controller, instead of
>
>     MyModel.create!(:ip => request.remote_ip, :description => 'request')
>
> do
>
>     model = MyModel.new
>     model.save  # this is important!
>     model.ip = request.remote_ip
>     model.description = 'request'
>     model.save
>
> then it works.
>
> Alexey.

I can't duplicate the op's problem: I can't get sqlite3 to show
X'3132372E302E302E31' for a string field.  It doesn't matter if I use
create(), or new() and save().  I get the following in both cases:

sqlite> .dump users
BEGIN TRANSACTION;
CREATE TABLE "users" ("id" INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL,
"name" varchar(255), "email" varchar(255), "created_at" datetime,
"updated_at" datetime, "last_sent_to" varchar(255));
INSERT INTO "users" VALUES(1,'127.0.0.1','request','2011-08-30
11:43:08.702303','2011-08-30 11:43:08.702303',NULL);
INSERT INTO "users" VALUES(2,'127.0.0.1','string','2011-08-30
11:43:08.710679','2011-08-30 11:43:08.710679',NULL);
COMMIT;
sqlite>



$ rails -v
Rails 3.0.9

$ ruby -v
ruby 1.9.2p180 (2011-02-18 revision 30909) [x86_64-darwin10.7.0]

$ sqlite3 -version
3.6.12


controller:

class PagesController < ApplicationController
  def home
    @title = "Home"
    @remote_ip = request.remote_ip
    @remote_ip_encoding = @remote_ip.encoding.name
    @str_literal_encoding = '127.0.0.1'.encoding.name

    User.create!(:name => request.remote_ip, :email => 'request')
    User.create!(:name => '127.0.0.1', :email => 'string')

=begin
    model.save  # this is important!
    model.name = request.remote_ip
    model.email = 'request'
    model.save

    model2 = User.new
    model2.save
    model2.name = '127.0.0.1'
    model2.email = 'string'
    modelT.save

    User.find_by_name('127.0.0.1')
=end

  end

  def about
    @title = "About"
  end

end
63c72161fba6e27cb05c078651c5e969?d=identicon&s=25 Alexey Muranov (alexey_m)
on 2011-08-30 14:01
Thanks, 7stud, the issue is solved with

  MyModel.create!(:ip => request.remote_ip.force_encoding('UTF-8'))

Apparently the sqlite adapter looks into the encoding before saving.
Still not clear if this should not be considered a bug.

Alexey.
54404bcac0f45bf1c8e8b827cd9bb709?d=identicon&s=25 7stud -- (7stud)
on 2011-08-30 14:06
I ran my action like this too:


class PagesController < ApplicationController
  def home
    @title = "Home"
    @remote_ip = request.remote_ip
    @remote_ip_encoding = @remote_ip.encoding.name
    @str_literal_encoding = '127.0.0.1'.encoding.name

    User.create!(:name => request.remote_ip, :email => 'request')
    User.create!(:name => '127.0.0.1', :email => 'string')

    model = User.new
    model.save  # this is important!
    model.name = request.remote_ip
    model.email = 'request'
    model.save

    model2 = User.new
    model2.save
    model2.name = '127.0.0.1'
    model2.email = 'string'
    model2.save

  end

  def about
    @title = "About"
  end

end


sqlite> .dump users
BEGIN TRANSACTION;
CREATE TABLE "users" ("id" INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL,
"name" varchar(255), "email" varchar(255), "created_at" datetime,
"updated_at" datetime, "last_sent_to" varchar(255));
INSERT INTO "users" VALUES(1,'127.0.0.1','request','2011-08-30
12:04:18.230500','2011-08-30 12:04:18.230500',NULL);
INSERT INTO "users" VALUES(2,'127.0.0.1','string','2011-08-30
12:04:18.237719','2011-08-30 12:04:18.237719',NULL);
INSERT INTO "users" VALUES(3,'127.0.0.1','request','2011-08-30
12:04:18.302252','2011-08-30 12:04:18.302252',NULL);
INSERT INTO "users" VALUES(4,'127.0.0.1','string','2011-08-30
12:04:18.307215','2011-08-30 12:04:18.307215',NULL);
COMMIT;
sqlite>
63c72161fba6e27cb05c078651c5e969?d=identicon&s=25 Alexey Muranov (alexey_m)
on 2011-08-30 14:06
7stud -- wrote in post #1019190:

> I can't duplicate the op's problem: I can't get sqlite3 to show
> X'3132372E302E302E31' for a string field.  It doesn't matter if I use
> create(), or new() and save().
>
> $ rails -v
> Rails 3.0.9
>
> $ ruby -v
> ruby 1.9.2p180 (2011-02-18 revision 30909) [x86_64-darwin10.7.0]
>
> $ sqlite3 -version
> 3.6.12

Strange, maybe it is a difference between Rails 3.0.X and Rails 3.1?
54404bcac0f45bf1c8e8b827cd9bb709?d=identicon&s=25 7stud -- (7stud)
on 2011-08-30 14:10
Alexey Muranov wrote in post #1019192:
> Thanks, 7stud, the issue is solved with
>
>   MyModel.create!(:ip => request.remote_ip.force_encoding('UTF-8'))
>
> Apparently the sqlite adapter looks into the encoding before saving.
>

When I do a bundle install, this is the only sqlite3 gem I see:

Using sqlite3 (1.3.3)

What version are you guys using?   Also what version of ruby, rails and
sqlite?  Mine are:


$ rails -v
Rails 3.0.9

$ ruby -v
ruby 1.9.2p180 (2011-02-18 revision 30909) [x86_64-darwin10.7.0]

$ sqlite3 -version
3.6.12
63c72161fba6e27cb05c078651c5e969?d=identicon&s=25 Alexey Muranov (alexey_m)
on 2011-08-30 14:47
7stud -- wrote in post #1019196:

> What version are you guys using?   Also what version of ruby, rails and
> sqlite?

$ rails -v
Rails 3.1.0.rc8

$ ruby -v
ruby 1.9.2p290 (2011-07-09 revision 32553) [x86_64-darwin10.8.0]

$ sqlite3 -version
3.7.7.1 2011-06-28 17:39:05
0bf1d837b23baa212858587f4361bc92?d=identicon&s=25 Alex Krivoshchekov (alexkrus)
on 2011-09-13 23:22
Alexey Muranov wrote in post #1019202:
> 7stud -- wrote in post #1019196:
>
>> What version are you guys using?   Also what version of ruby, rails and
>> sqlite?
>
> $ rails -v
> Rails 3.1.0.rc8
>
> $ ruby -v
> ruby 1.9.2p290 (2011-07-09 revision 32553) [x86_64-darwin10.8.0]
>
> $ sqlite3 -version
> 3.7.7.1 2011-06-28 17:39:05

Alexey,

I faced with the similar problem in slightly different environment:

(in simply controller)
...
hash = Digest::SHA2.hexdigest
[params[:document][:file].original_filename, current_user.email,
version].join
...
    if current_user.documents.create :path => file.to_s, :hashref =>
hash, :version => version,
...

(logs and dump)
...
INSERT INTO "documents" ("created_at", "description", "hashref",
"mimetype", "path", "updated_at", "user_id", "version") VALUES (?, ?, ?,
?, ?, ?, ?, ?)  [["created_at", Tue, 13 Sep 2011 17:43:16 UTC +00:00],
["description", nil],
> ["hashref", "18da91cbfadb74e43d9ca4231555462d"],
["mimetype", "[text/plain]"], ["path", "y1.txt"], ["updated_at", Tue, 13
Sep 2011 17:43:16 UTC +00:00], ["user_id", 1], ["version", 0]]

sqlite> .dump documents
INSERT INTO "documents"
VALUES(13,1,'y1.txt',
> X'3138646139316362666164623734653433643963613432333135353534363264',
NULL,'[text/plain]','2011-09-13
17:43:16.214665','2011-09-13 17:43:16.214665',0);

So I can't refer to this record using hash value.  But!  If I add just a
little modification to hash string, just a single char other than
[0-9a-f] (say hash += "*"), everything works well:

sqlite> .dump documents
INSERT INTO "documents"
VALUES(14,1,'test-text',
> '6c9034ddb7f1f248e6a215a1d335ff94*',
'tt1','[]','2011-09-13
17:59:25.925458','2011-09-13 17:59:25.925458',0);

I'm using Rails 3.1, Ruby 1.9.2p290 and sqlite 3.7.7.1.
63c72161fba6e27cb05c078651c5e969?d=identicon&s=25 Alexey Muranov (alexey_m)
on 2011-12-09 22:41
This is resolved in rails 3.1.3.  At least i tried and request.remote_ip
was stored correctly without need to enforce utf-8 encoding.
Please log in before posting. Registration is free and takes only a minute.
Existing account

NEW: Do you have a Google/GoogleMail, Yahoo or Facebook account? No registration required!
Log in with Google account | Log in with Yahoo account | Log in with Facebook account
No account? Register here.