Weird assignment problem, very confused :(

29 views
Skip to first unread message

sol

unread,
Aug 29, 2011, 12:04:40 PM8/29/11
to Ruby on Rails: Talk
Hey, I have the following line in my controller:

User.create(:email => "fu...@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 => "fu...@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

sol

unread,
Aug 29, 2011, 1:34:39 PM8/29/11
to Ruby on Rails: Talk
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>

On 29 Aug., 18:04, sol <ch.bl...@gmail.com> wrote:
> Hey, I have the following line in my controller:
>
> User.create(:email => "f...@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 => "f...@bar.com", :password =>

Frederick Cheung

unread,
Aug 29, 2011, 2:02:25 PM8/29/11
to Ruby on Rails: Talk


On Aug 29, 6:34 pm, 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

Alexey Muranov

unread,
Aug 29, 2011, 2:06:13 PM8/29/11
to rubyonra...@googlegroups.com
What does `User.first.ip.inspect` return in the two cases?

--
Posted via http://www.ruby-forum.com/.

sol

unread,
Aug 29, 2011, 5:08:47 PM8/29/11
to Ruby on Rails: Talk
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>
wrote:

Jeffrey L. Taylor

unread,
Aug 29, 2011, 5:13:05 PM8/29/11
to Ruby on Rails: Talk
Quoting sol <ch.b...@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

sol

unread,
Aug 29, 2011, 5:12:51 PM8/29/11
to Ruby on Rails: Talk
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

sol

unread,
Aug 29, 2011, 5:39:08 PM8/29/11
to Ruby on Rails: Talk
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

7stud --

unread,
Aug 29, 2011, 6:44:06 PM8/29/11
to rubyonra...@googlegroups.com
Christoph B. wrote in post #1019055:

> Hey, I have the following line in my controller:
>
> User.create(:email => "fu...@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 => "fu...@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.01'

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"

Alexey Muranov

unread,
Aug 30, 2011, 3:04:55 AM8/30/11
to rubyonra...@googlegroups.com
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.
> For example:
>

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.

Alexey Muranov

unread,
Aug 30, 2011, 3:17:18 AM8/30/11
to rubyonra...@googlegroups.com
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:
create two records in the database (with a string and with
request.remote_ip ),
see what is in the database,
verify that the records look identical, but find_by_ip returns only one?

This is what i would do.

sol

unread,
Aug 30, 2011, 4:07:24 AM8/30/11
to Ruby on Rails: Talk
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

On 30 Aug., 09:17, Alexey Muranov <li...@ruby-forum.com> wrote:
> 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_ipnot defined),

Alexey Muranov

unread,
Aug 30, 2011, 4:29:40 AM8/30/11
to rubyonra...@googlegroups.com
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.

Alexey Muranov

unread,
Aug 30, 2011, 4:41:47 AM8/30/11
to rubyonra...@googlegroups.com
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.

sol

unread,
Aug 30, 2011, 5:00:10 AM8/30/11
to Ruby on Rails: Talk
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

Alexey Muranov

unread,
Aug 30, 2011, 5:06:01 AM8/30/11
to rubyonra...@googlegroups.com
I also use sqlite in development, this is from my Gemfile:

group :development do
gem 'sqlite3'
end

Frederick Cheung

unread,
Aug 30, 2011, 5:43:11 AM8/30/11
to Ruby on Rails: Talk


On Aug 30, 9:07 am, 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

Alexey Muranov

unread,
Aug 30, 2011, 5:49:42 AM8/30/11
to rubyonra...@googlegroups.com
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'

sol

unread,
Aug 30, 2011, 5:56:08 AM8/30/11
to Ruby on Rails: Talk
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

On 30 Aug., 11:49, Alexey Muranov <li...@ruby-forum.com> wrote:
> 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 tohttp://localhost:3000/writer/write_records

7stud --

unread,
Aug 30, 2011, 5:58:03 AM8/30/11
to rubyonra...@googlegroups.com
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.

Alexey Muranov

unread,
Aug 30, 2011, 6:08:12 AM8/30/11
to rubyonra...@googlegroups.com
@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.

7stud --

unread,
Aug 30, 2011, 6:13:15 AM8/30/11
to rubyonra...@googlegroups.com
Alexey Muranov wrote in post #1019177:

Yes, Christoph linked to his sqlite dump, which showed the sane 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. 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 seems to
have backed off that statement because sqlite3 appears to provide loose
typing for columns. In any case, just because the column type is string
does not mean the types in the column are necessarily the same.

Alexey Muranov

unread,
Aug 30, 2011, 6:32:43 AM8/30/11
to rubyonra...@googlegroups.com
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.

7stud --

unread,
Aug 30, 2011, 6:45:41 AM8/30/11
to rubyonra...@googlegroups.com
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.

7stud --

unread,
Aug 30, 2011, 7:45:12 AM8/30/11
to rubyonra...@googlegroups.com
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.

7stud --

unread,
Aug 30, 2011, 7:52:00 AM8/30/11
to rubyonra...@googlegroups.com
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>

Alexey Muranov

unread,
Aug 30, 2011, 8:01:25 AM8/30/11
to rubyonra...@googlegroups.com
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.

7stud --

unread,
Aug 30, 2011, 8:06:21 AM8/30/11
to rubyonra...@googlegroups.com
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>

Alexey Muranov

unread,
Aug 30, 2011, 8:06:57 AM8/30/11
to rubyonra...@googlegroups.com
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?

7stud --

unread,
Aug 30, 2011, 8:10:45 AM8/30/11
to rubyonra...@googlegroups.com
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

--
Posted via http://www.ruby-forum.com/.

Alexey Muranov

unread,
Aug 30, 2011, 8:47:55 AM8/30/11
to rubyonra...@googlegroups.com
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

Alex Krivoshchekov

unread,
Sep 13, 2011, 5:22:49 PM9/13/11
to rubyonra...@googlegroups.com
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.

Alexey Muranov

unread,
Dec 9, 2011, 4:41:43 PM12/9/11
to rubyonra...@googlegroups.com
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.
Reply all
Reply to author
Forward
0 new messages