> For example in one test, in flwor_expr object, theClauses was receiving
> another flwor_clause in the vector, which made the vector to increase and move
> to another space. But the initial flwor_clause had already been serialized,
> and its address was registered for address duplication detection. Sometimes
> another object would be allocated at the same address, and the plan serializer
> thought it is the same object. This only occured sometimes, so the problem was
> hard to debug.
> So as a rule, all the objects should freeze during plan serialization, nothing
> should change.
I am sorry, but this still does not answer my question. I assume that the
flwor_expr is inside the body of a udf. Are you saying that this body is
somehow serialized, without having being optimized yet? If yes, I don't
understand how this is possible, given that user_function::serialize() will
first optimize the body (if not optimized already) before serializing it.
Either I am missing something, or the real bug is somewhere else and you are
just covering it up with this patch.
Your team Zorba Coders is requested to review the proposed merge of
lp:~danielturcanu/zorba/plan-serializer into lp:zorba.
Mailing list: https://launchpad.net/~zorba-coders
Post to : firstname.lastname@example.org
Unsubscribe : https://launchpad.net/~zorba-coders
More help : https://help.launchpad.net/ListHelp