> 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. -- https://code.launchpad.net/~danielturcanu/zorba/plan-serializer/+merge/88783 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 : zorba-coders@lists.launchpad.net Unsubscribe : https://launchpad.net/~zorba-coders More help : https://help.launchpad.net/ListHelp
