I was going for this approach on a project a while ago... didn't do it
in the end though.

I'm sure that it's always possible to avoid having to do this, but in
some cases it might be well worth it.

There doesn't seem to be an easy, well-documented way of handling this
sort of thing. I mean, where do you put the serialize() function -
Model::set(), Model::deconstruct() ? Model::deconstruct() seems like
the most likely place but how exactly does it work.

And then where's the unserialize() go? Model::afterFind() seems to be
the best place, but depending on the find type and whether the model
was called directly or as an association changes the structure of the
data array [at least it used to in an older version - this might not
be the case any more].

It would be so much easier if the special handling for date fields was
in an external behavior; all in one place so you could learn by
example.


On May 2, 12:36 pm, validkeys <[EMAIL PROTECTED]> wrote:
> I have an app which has 2 types of quote requests. Rather that have 2
> seperate tables with tons of fields, I serialize all of the form data
> and just store it in one field. Besides the obvious searching
> downside, is there any practical or standards downside to what i am
> doing?
>
> I only ask because i am preparing for another project that might be
> using serialize quite a lot and want to make sure that i am not being
> a total moron in using serialize before i start planning for the
> project.
>
> Thanks!
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"CakePHP" 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/cake-php?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to