Replace the class variable with a method call instead?
On Jun 10, 7:48 pm, Jodi Showers wrote:
> Makund - it is quite likely that your solution will break when
> multithreading arrives (as will will loads of other stuff)
>
--~--~-~--~~~---~--~~
You received thi
>
> > > Makund - it is quite likely that your solution will break when
> > > multithreading arrives (as will will loads of other stuff)
>
You could try using Thread.current in your model when storing your
class variable.
For example, in your User model, you could have the following methods:
d
Basically... the class variable is shared by all instances of the
controller in question spawned by the Rack server process.
Multithreaded Rails handles multiple requests simultaneously, and thus
multiple simultaneous instances of the controller. Two requests come
along, one from 1.1.1.1, then one
009/6/10 Jodi Showers :
>
> Makund - it is quite likely that your solution will break when
> multithreading arrives (as will will loads of other stuff)
Could you explain why please, for the uninitiated?
Thanks
Colin
--~--~-~--~~~---~--~~
You received this message
Makund - it is quite likely that your solution will break when
multithreading arrives (as will will loads of other stuff)
On 9-Jun-09, at 6:41 AM, Mukund wrote:
>
> Have a look at active_record::observers and wrap the save method with
> an update to the ip address. Declare a class level varia
Have a look at active_record::observers and wrap the save method with
an update to the ip address. Declare a class level variable in
application.rb with a before_filter that populates the IP into the
variable (and subsequently used by the observer).
On Jun 9, 2:44 am, Chris wrote:
> As part o
2009/6/8 Chris :
>
> As part of my project, I need to store IP address for every object
> that was created.
>
> User
> Topic
> Payment
> and more...
>
> Now all these records have the following attribute in their table
> called "ip_address_on_create".
>
> One way to do this is to put this code
or rather you're more likely going to be doing params[:user].merge!...
but you get the idea
On Jun 8, 7:45 pm, pharrington wrote:
> I haven't tested this at all, and to be quit honest it feels a bit
> hackish, but the following comes to mind:
>
> before_filter lambda { params.merge! :ip_address_
I haven't tested this at all, and to be quit honest it feels a bit
hackish, but the following comes to mind:
before_filter lambda { params.merge! :ip_address_on_create =>
request.remote_ip }
Add the appropriate attribute to attr_accessible and you'll be good to
go.
On Jun 8, 5:44 pm, Chris wro
9 matches
Mail list logo