NullPointerException on Deserialization of a QTuple

[dmiorandi]

in #640 was solved QTuple SerializationException but I've seen now that Deserialization (of QTuple) is not working cause a null pointer on DslExpression class calling hashCode method.

I've patch myself the DslExpression class changing hashCode method like this...

    @Override
    public final int hashCode() {
        return mixin==null?-1:mixin.hashCode();
    }

I can't figure out if this is the right behavior but it works. Please consider if this can be integrated in your code (or if there is a cleaner approach).

Can you add to your serialization method used on tests also deserialization, something like this?

    protected Object serializeDeserialize(Object obj) throws IOException, ClassNotFoundException{
        ByteArrayOutputStream fileOut = new ByteArrayOutputStream();
        ObjectOutputStream out = new ObjectOutputStream(fileOut);
        out.writeObject(obj);

        ByteArrayInputStream fileIn = new   ByteArrayInputStream(fileOut.toByteArray());
        ObjectInputStream in = new ObjectInputStream(fileIn);
        Object objReaded = in.readObject();     
        in.close();
        out.close();
        fileOut.close();
        return objReaded;
    }

[timowest]

Deserialization seems to crash with RelationalPathBase.columnMetadata creation

[timowest]

The implemention with the eager calculation is not optimal from a performance point of view, but it is stable and simple. Feel free to suggest alternatives.

Returning -1 for mixin == null will not work, since this will create changing hash codes. The mixin field will be populated after the object has been fully populated.

[dmiorandi]

I didn't understand completly your response.

If understand #676 solve this issue, right?
About the eager solution you mean to calculating hashcode in the constructor? A this time I have got not suggestion to you.

[timowest]

If understand #676 solve this issue, right?

Both your patch and my commit provide a solution

About the eager solution you mean to calculating hashcode in the constructor?

With eager calculation I mean the calculation in the constructor which has the benefit that the hashCode will be directly available when deserialized, and it will be the correct one.

Returning -1 for the hashCode has the problem that this will corrupt usage as the hashCode changes when the object is fully initialized.

[dmiorandi]

Imho, this is a good solution at now.

[timowest]

Released in 3.3.2