hoaproject/Ruler

avoid use of serialize

Grummfy opened this issue · 7 comments

Grummfy commented

Hello,
in the documentation of hoa ruler we find this

// We serialize and save the object model.
$database->save($ruleId, serialize($model));

But we should avoid serialize for long storage. Why, because serialize lead on php model, and this model can evolve with PHP imself. So a value in the database can become invalid because of the php version have change. But there is also another issue. If you have an evolution of hoa\ruler, it's possible that the serialisation of the object differ from one version to another.

We can imagine use json or other serialisation model.

Hywan commented

Agree. I am asking a peer review from @stephpy :-).

stephpy commented

Hi,

You're right, that's why we store rule customer.id = x and not the compiled php.

It begin to be tricky, having a rule in "sql" then a compiled php object in "json", no ?

Hywan commented

Instead of serializing to PHP, we could implement the JsonSerializable interface and therefore serialize to JSON?

stephpy commented

Not sure it fixes the issues. If serialize method in PHP can't deal with new structure object, I guess JsonSerializable will too.

An idea is to version the rules, but it looks over engineered.

Since our goal is to serialize a code part, IMO it's difficult to find a system ... Or we have to write our own system but at this moment, stocking the rule is the best solution.

We could recommand to users to store rule and serialized php object rule, and in case of unserialization fail, user'll have to use the rule.

Thoughts ?

Hywan commented

Seems good to me. Didn't meet this usecase so far, which is logical because no regression has been introduced yet.

/cc @hoaproject/hoackers

stephpy commented

Hi, I guess we could close this one. :)

Hywan commented

👍