TypeSerializer returned wrong type: expected a long but got a class java.lang.Long on every delete

[rothschild86]

With every Delete(), i see a bunch of these in logcat (one for each deleted row):

12-01 22:43:18.597: V/ActiveAndroid(31299): DELETE FROM StuffEntity WHERE PersonaId = ? AND Status = ? AND PendingChanges = 0 1,10 12-01 22:43:18.607: W/ActiveAndroid(31299): TypeSerializer returned wrong type: expected a long but got a class java.lang.Long 12-01 22:43:18.607: W/ActiveAndroid(31299): TypeSerializer returned wrong type: expected a long but got a class java.lang.Long 12-01 22:43:18.617: W/ActiveAndroid(31299): TypeSerializer returned wrong type: expected a long but got a class java.lang.Long 12-01 22:43:18.617: W/ActiveAndroid(31299): TypeSerializer returned wrong type: expected a long but got a class java.lang.Long 12-01 22:43:18.617: W/ActiveAndroid(31299): TypeSerializer returned wrong type: expected a long but got a class java.lang.Long 12-01 22:43:18.617: W/ActiveAndroid(31299): TypeSerializer returned wrong type: expected a long but got a class java.lang.Long 12-01 22:43:18.627: W/ActiveAndroid(31299): TypeSerializer returned wrong type: expected a long but got a class java.lang.Long

I use integers for id's. don't know how Longs come into play here.

[johnhamelink]

I get this as well when saving the following model (note that there are no longs):

https://gist.github.com/johnhamelink/19cabe7b221585f87b7d

[rusfearuth]

Could you write more complete example?

[sbuettner]

This may be due to

fieldType = value.getClass();
// check that the serializer returned what it promised
if (!fieldType.equals(typeSerializer.getSerializedType())) {
  Log.w(String.format("TypeSerializer returned wrong type: expected a %s but got a %s",   typeSerializer.getSerializedType(), fieldType));
}

in the Model.java file lines 94-99. Long doenst equal ``long`. Same with int and Integer etc. May be something like this would help: https://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/ClassUtils.html#isAssignable(java.lang.Class, java.lang.Class, boolean)

[joshuapinter]

We were also seeing this. @sbuettner put me on the right path.

In our case, we are using JodaTime for DateTime fields like created_at, updated_at, etc.:

@Expose
@Column
public DateTime created_at;

@Expose
@Column
public DateTime updated_at;

In order to use JodaTime's DateTime as a column type, we need to write a serializer for ActiveAndroid. This is what it looked like:

package com.activeandroid.serializer;

import org.joda.time.DateTime;

public final class JodaDateTimeSerializer extends TypeSerializer {
	public Class<?> getDeserializedType() {
		return DateTime.class;
	}

	public Class<?> getSerializedType() {
		return long.class;
	}

	public Long serialize(Object data) {
		if (data == null) {
			return null;
		}

		return ((DateTime) data).getMillis();
	}

	public DateTime deserialize(Object data) {
		if (data == null) {
			return null;
		}

		return new DateTime().withMillis((Long)data);
	}
}

You can see that getSerializedType is returning a long class but the serialize method actually returns a Long class.

Not sure why this slipped through the cracks or why it is only appearing in our logs now, but to fix this we just had to adjust the getSerializedType to return a Long class instead:

package com.activeandroid.serializer;

import org.joda.time.DateTime;

public final class JodaDateTimeSerializer extends TypeSerializer {
	public Class<?> getDeserializedType() {
		return DateTime.class;
	}

	public Class<?> getSerializedType() {
		return Long.class;
	}

	public Long serialize(Object data) {
		if (data == null) {
			return null;
		}

		return ((DateTime) data).getMillis();
	}

	public DateTime deserialize(Object data) {
		if (data == null) {
			return null;
		}

		return new DateTime().withMillis((Long)data);
	}
}

Hope that helps others that may be using their own serializers.

[rothschild86]

Nice find 8 years later! 💪

[joshuapinter]

Legacy code FTW!