Issue has been resolved.  I had a DateTime in there that I hadn't
converted to a string.  For anyone else's benefit that may stumble
upon this, here's some relevant code snippets that worked out for me:

Class Declaration

class Users implements UserInterface, \Serializable {

Serialize/Unserialize Methods (Not sure if it's the right way or the
wrong way, but it's the Webb way and it works for now):

    public function serialize() {
        return implode(',', array(
            'user_id'     => $this->getUserId(),
            'username'    => $this->getUsername(),
            'password'    => $this->getPassword(),
            'user_active' => $this->getUserActive(),
            'user_date'   => $this->getUserDate()->format('m/d/Y')
        ));
    }


    public function unserialize($strSerialized) {
        $serialized = explode(',', $strSerialized);

        $this->setUserId($serialized[0]);
        $this->setUsername($serialized[1]);
        $this->password = $serialized[2];
        $this->setUserActive($serialized[3]);
        $this->setUserDate(new \DateTime($serialized[4]));
    }


On May 23, 12:30 pm, Roger Webb <webb.ro...@gmail.com> wrote:
> Until the BETA2 update I was getting warnings related to serializing
> the User Entity, it is a breaking problem in beta2.  So, I googled
> around and found this:
>
> http://groups.google.com/group/symfony-users/browse_thread/thread/54c...
>
> Following the advice there, I created serialize() and unserialize()
> methods and had my "Users" class implement \Serializable.  I tried
> returning an array, which through the following Exception:
>
> "Symfony\Component\Security\Core\Authentication\Token
> \UsernamePasswordToken::serialize() must return a string or NULL"
>
> I returned null and it worked but it rendered the Entity returned by
> $this->get('security.context') and it's twig counterpart useless
> because it contained no data.
>
> So, I tried imploding the array and returning that and was met with
> the Exception noted above.
>
> I also tried looking through the "Security" chapter in the book and
> could not find any  information about how to or what to serialize.
> Can anyone point me to a resource that explains how to do this in a
> Symfony-appropriate way?
>
> Roger
>
> On May 17, 1:58 am, Marco Pivetta <ocram...@gmail.com> wrote:
>
>
>
>
>
>
>
> > I usually build stuff like this when making a multi-step form with different
> > http requests:
>
> > request 1:
> > $ns = new \Zend_Session_Namespace('test'); //don't care about it, I usually
> > work with ZF
> > /* We suppose this is my entity fetched by some kind of voodoo query or
> > complex stuff that can be done only in step 1 (picker?) */
> > $modifiedUser = $em->getRepository('My\User')->findOneBy(array('fullname' =>
> > 'Marco Pivetta'));
> > $em->detach($modifiedUser);
> > $ns->user = $modifiedUser;
>
> > request 2:
> > $ns = new \Zend_Session_Namespace('test');
> > //Bringing my user entity back to life!
> > $modifiedUser = $ns->user;
> > $em->merge($modifiedUser);
> > $em->refresh($modifiedUser); //Yeah, this is overhead, but it solved a LOT
> > of troubles in my case...
> > $modifiedUser->doStuff();
> > //Now again, for the next step! And so on and on and on...
> > $em->detach($modifiedUser);
> > $ns->user = $modifiedUser;
>
> > request 3:
> > //repeat stuff like request 2 here!
>
> > Marco Pivetta
> > @Ocramius <http://twitter.com/Ocramius>http://marco-pivetta.com
>
> > On 17 May 2011 04:53, Luis Cordova <cordo...@gmail.com> wrote:
>
> > > yes and if you find a resource or more styled example or post that can
> > > clarify this further would be great
>
> > > On Mon, May 16, 2011 at 9:48 PM, oscar balladares <liebegr...@gmail.com>
> > > wrote:
> > > > Another issue that I run into is:
> > > > Let's say we have object A, and object A has refernce to Object B, both
> > > are
> > > > entities instances, and reference of B is actually a proxy.
> > > > This is the case when retrieving A with the entity manager. The 
> > > > reference
> > > of
> > > > Object B is a doctrine proxy of Object B actually.
> > > > So when serializing A, reference to B will be set to NULL. And this
> > > > behaviour is explained in Doctrine Docs. They advice to not to
> > > > serialize Entities (that are being managed by an entity manager).
> > > > Now I'm facing this problem. Even using \Serializable interface. I read
> > > > about a guy that hacked the source code of doctrine (proxies) to
> > > > allow serialization but never explained how.
> > > > So my big question is: If serializing entities is not adviced, how can I
> > > > solve my use case?
> > > > I'm implementing a shopping cart, and serializing products entities
> > > > instances and saving them in a Session variable.
> > > > I hate using arrays when I could achive the same with POO.
> > > > But, I must remark that this is a Doctrine/PHP issue not a Symfony
> > > Framework
> > > > related one.
> > > > I'll keep searching. Any usefull information will be posted here to help
> > > > someone ;)
> > > > 2011/5/16 Luis Cordova <cordo...@gmail.com>
>
> > > >> someone has to write about this case more clearly to explain to all
>
> > > >> This example is perfect, although one more could be added
>
> > > >> Even though is not sf2 related specifically I think that it has to be
> > > >> explained since we are going to run into these kind of problems
>
> > > >> Thanks
>
> > > >> On Mon, May 16, 2011 at 10:43 AM, oscar balladares <
> > > liebegr...@gmail.com>
> > > >> wrote:
> > > >> > Yes, you are right. I hadn't try out the ->detach() method :P Sorry. 
> > > >> > I
> > > >> > saw a
> > > >> > tutorial that seemed very convincing :P (it was very late when posted
> > > >> > last
> > > >> > email and I didn't try it till now).
> > > >> > My apologies :F
>
> > > >> > 2011/5/16 Marco Pivetta <ocram...@gmail.com>
>
> > > >> >> Careful! The entity manager's detach method does not return 
> > > >> >> anything!
> > > >> >> Marco Pivetta
> > > >> >> @Ocramius
> > > >> >>http://marco-pivetta.com
>
> > > >> >> On 16 May 2011 08:55, oscar balladares <liebegr...@gmail.com> wrote:
>
> > > >> >>> According what I have read so far, serialize/unserialize $entities
> > > >> >>> with
> > > >> >>> proxies associations is not advised.
> > > >> >>> And of course, if you are saving objects in session() vars, it is 
> > > >> >>> an
> > > >> >>> innecesary load to save proxies information.
> > > >> >>> So, it is adviced to detach proxies from entities (in case where
> > > >> >>> entites
> > > >> >>> are retrieved with the entity_manager).
> > > >> >>> For example:
> > > >> >>> public function someControllerAction($product_id)
> > > >> >>> {
> > > >> >>>     $product = $em->find('Vendor\someBundle\Entity\Product',
> > > >> >>> $product_id);
> > > >> >>>     //If you need to save the $product object in a session var, for
> > > >> >>> example in a shopping cart implementation, which is actually the 
> > > >> >>> one
> > > >> >>> that
> > > >> >>>     // lead me to the issue/solution in first place.
> > > >> >>>     //so, to detach proxy information from $product you must:
>
> > > >> >>>     $product = $em->detach($product);
> > > >> >>>     //then serialize it and save it in a session var.
> > > >> >>> }
>
> > > >> >>> If during unserialization you need the proxy information back, you
> > > >> >>> should
> > > >> >>> $product = unserialize($SerializedProductContainer);
> > > >> >>> $product = $em->merge($product);
> > > >> >>> Then you should be able to use proxy information of $product to
> > > >> >>> retrieve
> > > >> >>> associated entities (Lazy load).
> > > >> >>> 2011/5/16 oscar balladares <liebegr...@gmail.com>
>
> > > >> >>>> Hi Luis, I solved the problem.
> > > >> >>>> Before making the summary I must point that Tim was reffering to
> > > what
> > > >> >>>> I
> > > >> >>>> thoght was "Serializable" about erroneously, sorry, my fault :D
> > > >> >>>> What I found (I have to start reading docs more deeply :P):
> > > >> >>>> The PHP bible says:
> > > >> >>>> "serialize() checks if your class has a function with the magic
> > > >> >>>> name __sleep. If so, that function is executed prior to any
> > > >> >>>> serialization.
> > > >> >>>> It can clean up the object and is supposed to return an array with
> > > >> >>>> the names
> > > >> >>>> of all variables of that object that should be serialized. If the
> > > >> >>>> method
> > > >> >>>> doesn't return anything then NULL is serialized and E_NOTICE is
> > > >> >>>> issued."
> > > >> >>>> E_NOTICE  is what I was getting in dev enviroment when trying to
> > > >> >>>> serialize an entity object that has reference to another entity
> > > >> >>>> object (due
> > > >> >>>> to associations). The serializations succeeded but I was getting
> > > that
> > > >> >>>> buggy
> > > >> >>>> message >:(
> > > >> >>>> The PHP bible says:
> > > >> >>>> "It is not possible for __sleep to return names of private
> > > properties
> > > >> >>>> in
> > > >> >>>> parent classes. Doing this will result in an E_NOTICE level error.
> > > >> >>>> Instead
> > > >> >>>> you may use the Serializableinterface."
> > > >> >>>> So I found that Doctrine (I think in proxies) use the magic
> > > function
> > > >> >>>> "__sleep()", so "serialize()" function exectues _sleep() method
> > > >> >>>> first, and
> > > >> >>>> expect it to return the object's properties, but if they are
> > > private
> > > >> >>>> it will
> > > >> >>>> fail, so if you change them to protected it will succeed.
> > > >> >>>> But changing properties scope is clumsy. \Serializable interface 
> > > >> >>>> is
> > > >> >>>> the
> > > >> >>>> solution, and this is the "how" IMHO :D
> > > >> >>>> Class object implements \Serializable
> > > >> >>>> {
> > > >> >>>>   private $name;
> > > >> >>>>   private $address = array();
> > > >> >>>>   public function serialize()
> > > >> >>>>   {
> > > >> >>>>      return $data = array('name' => $this->name, 'address' =>
> > > >> >>>> $this->address;
> > > >> >>>>   }
> > > >> >>>>   public function unserialize($serialized)
> > > >> >>>>   {
> > > >> >>>>     $data = unserialize($serialized);
> > > >> >>>>     $this->name = $data['name'];
> > > >> >>>>     $this->address = $data['address'];
> > > >> >>>>   }
> > > >> >>>>   //setters and getters for $name and $address
> > > >> >>>> }
> > > >> >>>> Class object must implement \Serializable, this way when
> > > >> >>>> serializing/unserializing the object, this will trigger the look
> > > for
> > > >> >>>> its two
> > > >> >>>> abstract implementation methods: serialize() and unserialize()
> > > >> >>>> This way, "serialize" will have access to private members for
> > > >> >>>> serialization, and when "unserialize" will look for the object's
> > > >> >>>> method
> > > >> >>>> "unserialize" and will set unserialized $data to its private
> > > members.
> > > >> >>>> Both methods are like bridges to the private members.
> > > >> >>>> Notice that if Object A has a reference to Object B (like in
> > > >> >>>> associations) Object B has to implement \Serializabe as well.
> > > >> >>>> And hope this help someone when having this same issue (that has
> > > >> >>>> nothing
> > > >> >>>> to do with the framework itself, but PHP )
> > > >> >>>> Regards!
> > > >> >>>> 2011/5/15 Luis Cordova <cordo...@gmail.com>
>
> > > >> >>>>> nobody is doubting that Tim
>
> > > >> >>>>> On Sun, May 15, 2011 at 7:48 PM, Tim...
>
> read more »

-- 
If you want to report a vulnerability issue on symfony, please send it to 
security at symfony-project.com

You received this message because you are subscribed to the Google
Groups "symfony users" group.
To post to this group, send email to symfony-users@googlegroups.com
To unsubscribe from this group, send email to
symfony-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/symfony-users?hl=en

Reply via email to