0

The issue is to save an object and retrieve it back the way it was before saving. Currently serializing the object -> saving the serialized as a file -> unserializing the file works. But what if I want to save the object in database? (While in mind that storing a serialized object in a database is not a good practice, since my object can get really big)

In this case, I have a data-access-layer which takes the object's properties and maps them to a table's fields. The question is how to read the data back into the same object as it was before saving? Something like what unserialize() does would fit the issue: it creates an object from the given data without hitting the constructor or anything else.

Let's say this is the class I want to store in the DB:

class MyClass {
    private $property;

    public function __construct(string $required_data) {
        if(empty($required_data)) throw new Exception("Cannot be empty");
    }

    public function load($arr) {
        foreach($arr as $key => $value) {
            $this->$key = $value;
        }
    }
}

Obviously that load() method up there, and something like the code below won't work in this case:

$obj = new MyClass(); // Throws an exception
$obj->load(['property' => 'value']);
ttvd94
  • 307
  • 3
  • 13
  • [This answer](https://stackoverflow.com/a/9812059/4362965) is the closest solution but I think there should be a more straightforward workaround. – ttvd94 Aug 16 '21 at 20:10
  • What is the problem if you serialize & save it to a TEXT column, and unserialize it back upon reading? The same can be achieved with json_encode/decode too. I find the JSON way better, as serialize may cause trouble if (in case) the TEXT data ever gets a change in length, even if white space. – Broken Arrow Aug 16 '21 at 20:14
  • What you are asking about is the literal definition of serialization, and there is nothing wrong with storing the serialized representation of an object in a system _that you control_. What is not recommended is accepting serialized objects from, or transmitted via, untrusted parties. So the answer is either "use `serialize()` and `unserialize()`" or you elaborate more on why you can't. – Sammitch Aug 16 '21 at 21:46
  • Thanks @Sammitch but my objects can get really big, maybe over 4 MB. Like [this answer](https://stackoverflow.com/a/16859775/4362965) mentions, I think it's not a good idea to store such large string in a DB (which seems to be "the easiest way"). If you disagree please let me know why – ttvd94 Aug 16 '21 at 23:56
  • 1
    The main thrust of that answer is that storing the data in a properly-normalized form would be preferable to storing an opaque blob of text, which is correct. It is not a general condemnation of storing serialized objects in a database. If you _can_ reasonably transform the objects' data into normalized data, then by all means that is what you _should_ do. But if that's not an option then it's perfectly acceptable to call `serialize()` and insert it into a `BLOB` [or non-mysql equivalent] field, even if it's 4MB. – Sammitch Aug 17 '21 at 00:04
  • @BrokenArrow my object can be very large and it may cause trouble when inserting in the DB. Also I don't know how json_decode can recreate the same class object. As far as I know json_encode does not include class names. – ttvd94 Aug 17 '21 at 00:08

0 Answers0