On Nov 18, 2:55 pm, Nik B <[EMAIL PROTECTED]> wrote:
> That's the issue with (perhaps poor) design -  it's a temporary object
> never stored on the server. It's attributes are defined merely with
> attr_accessor's. At the end of the checkout process the virtual
> attributes are stored on Authorize.NET, and the actual record
> attributes are just an id and a customer_address_id which is used to
> retrieve it on Authorize.
>
in that case I'd store a hash of those attributes in the session
> Seems like perhaps it has something to do with the attributes_cache...
> but I can't find much information on how the attributes cache works.
>
Unlikely. attributes_cache is just to do with caching attributes that
are expensive to create (mostly datetimes)

Fred

> On Nov 18, 9:49 am, Frederick Cheung <[EMAIL PROTECTED]>
> wrote:
>
> > On 18 Nov 2008, at 14:38, Nik B wrote:
>
> > > I didn't think I was storing soap objects... here is the object that
> > > is the last think I store and retrieve from the session:
>
> > Well the backtrace certain showed the soap serialization stuff getting  
> > called. if you're storing an activerecord objects you'll save yourself  
> > trouble by just storing its attributes (or just its id if its already  
> > saved).
>
> > Fred
>
> > > --- !ruby/object:ShippingAddress
> > > address: 123 MAIN ST
> > > attributes:
> > >  customer_address_id:
> > >  preview:
> > >  user_id:
> > >  label:
> > > attributes_cache: {}
>
> > > city: ANYTOWN
> > > country: US
> > > first_name: Firstname
> > > last_name: Lastname
> > > new_record: true
> > > phone_number: 555-555-5555
> > > residential: true
> > > state: NC
> > > zip: 55555-5555
>
> > > On Nov 17, 7:27 pm, Frederick Cheung <[EMAIL PROTECTED]>
> > > wrote:
> > >> You're storing soap objects in your session ? I'm guessing wildly but
> > >> I'd guess that what's in the session references a class that was
> > >> unloaded between the two requests, so the unmarshaling code fails
> > >> horribly (if turning config.cache_classes on makes the problem go  
> > >> away
> > >> then that would be a strong indication that something of that nature
> > >> is the problem). One way around this would be to only store primitive
> > >> types like arrays and hashes in the session.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Talk" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to