RushOrm
RushOrm copied to clipboard
NumberFormatException invalid int
Hi, i saw the Issue with the NumberFormatExcpt here: https://github.com/Stuart-campbell/RushOrm/issues/34
And this bug should be fixed in v1.1.5. We're using v1.1.7 in our project and we get a lot of NumberFormat Excpetions like these:
Fatal Exception: java.lang.NumberFormatException: Invalid int: "2.75"
at java.lang.Integer.invalidInt(Integer.java:138)
at java.lang.Integer.parse(Integer.java:410)
at java.lang.Integer.parseInt(Integer.java:367)
at java.lang.Integer.parseInt(Integer.java:334)
at co.uk.rushorm.core.implementation.RushColumnInt.deserialize(RushColumnInt.java:22)
at co.uk.rushorm.core.implementation.RushColumnInt.deserialize(RushColumnInt.java:9)
at co.uk.rushorm.core.implementation.RushColumnsImplementation.setField(RushColumnsImplementation.java:50)
at co.uk.rushorm.core.implementation.ReflectionClassLoader.loadClass(ReflectionClassLoader.java:99)
at co.uk.rushorm.core.implementation.ReflectionClassLoader.loadClasses(ReflectionClassLoader.java:54)
at co.uk.rushorm.core.implementation.ReflectionClassLoader.loadClasses(ReflectionClassLoader.java:42)
at co.uk.rushorm.core.RushCore.load(RushCore.java:608)
at co.uk.rushorm.core.RushCore.load(RushCore.java:257)
at co.uk.rushorm.core.RushSearch.find(RushSearch.java:41)
Caused by java.lang.NumberFormatException: Invalid int: "OCZ ARC 100 SERIES 480GB
"
at java.lang.Integer.invalidInt(Integer.java:138)
at java.lang.Integer.parse(Integer.java:410)
at java.lang.Integer.parseInt(Integer.java:367)
at java.lang.Integer.parseInt(Integer.java:334)
at co.uk.rushorm.core.implementation.RushColumnInt.deserialize(RushColumnInt.java:22)
at co.uk.rushorm.core.implementation.RushColumnInt.deserialize(RushColumnInt.java:9)
at co.uk.rushorm.core.implementation.RushColumnsImplementation.setField(RushColumnsImplementation.java:50)
at co.uk.rushorm.core.implementation.ReflectionClassLoader.loadClass(ReflectionClassLoader.java:99)
at co.uk.rushorm.core.implementation.ReflectionClassLoader.loadClasses(ReflectionClassLoader.java:54)
at co.uk.rushorm.core.implementation.ReflectionClassLoader.loadClasses(ReflectionClassLoader.java:42)
at co.uk.rushorm.core.RushCore.load(RushCore.java:608)
at co.uk.rushorm.core.RushCore.load(RushCore.java:257)
at co.uk.rushorm.core.RushSearch.find(RushSearch.java:41)
Caused by java.lang.NumberFormatException: Invalid int: "zotac"
at java.lang.Integer.invalidInt(Integer.java:138)
at java.lang.Integer.parse(Integer.java:410)
at java.lang.Integer.parseInt(Integer.java:367)
at java.lang.Integer.parseInt(Integer.java:334)
at co.uk.rushorm.core.implementation.RushColumnInt.deserialize(RushColumnInt.java:22)
at co.uk.rushorm.core.implementation.RushColumnInt.deserialize(RushColumnInt.java:9)
at co.uk.rushorm.core.implementation.RushColumnsImplementation.setField(RushColumnsImplementation.java:50)
at co.uk.rushorm.core.implementation.ReflectionClassLoader.loadClass(ReflectionClassLoader.java:99)
at co.uk.rushorm.core.implementation.ReflectionClassLoader.loadClasses(ReflectionClassLoader.java:54)
at co.uk.rushorm.core.implementation.ReflectionClassLoader.loadClasses(ReflectionClassLoader.java:42)
at co.uk.rushorm.core.RushCore.load(RushCore.java:608)
at co.uk.rushorm.core.RushCore.load(RushCore.java:257)
at co.uk.rushorm.core.RushSearch.find(RushSearch.java:41)
and so on. It seems that rushorm is mixing up some values from different variables when deserializing. The next problem is - i cannot reproduce this behavior but there are a lot of crashes in our developer console with such kind of log messages.
Most of the crashes happen on Sony or Samsung Devices with Android 5 (82% 5.1.1, 8% 5.0.2)
And not only in one Modelclass but in nearly everyone. For example:
public class Product extends RushObject implements Serializable {
@SerializedName("id")
private Integer productId;
@SerializedName("best_avl")
private int bestAvailability;
@SerializedName("offer_count")
private int offerCount;
private String title;
@SerializedName("subtitle")
private ArrayList<String> subtitle = new ArrayList<>();
private String description;
@SerializedName("rating_count")
private float ratingCount;
@SerializedName("rating_stars")
private float ratingStarts;
@SerializedName("rating_percent")
private float ratingPercent;
@SerializedName("best_price")
private String bestPrice;
}
Do you have any idea how we can fix this bug?
+1 I have same problem running 1.1.11 rush version
Any updates to this issue? It maybe is a reflection error? We really have to get rid about this strange bug :/
If you reproduce it easily can you try adding this meta tag to your manifest with a clean db.
<meta-data android:name="Rush_order_alphabetically" android:value="true" />
Then see if it is still present?
Thanks
Thank u for the quick response. Hm, I'll try it, but the problem is that i can't reproduce this error / behaviour. I just see the logs from the crashes. Will or could this work with an existing database too?
It should work if you increate the db version might be worth checking, quite a new feature.
Ill try reproduce later.
What i don't unterstand is how changing the order should affect the library to choose the right parameter names when deserializing?!
I wondering if there is an issue with the getFields reflection method. The docs do say is does not guarantee order and originally I went with the assumption it would always be the same order on any one device. But if the os version changes on the device that order could have changed. Bit of a long shot but not sure how else the orders could differ unless the sql cursor returns the fields in a different order to how they are in the db.
Added that meta data tag sorts the fields after calling getFields.
Ok I will give it a try!
So we just released this fix, but the error still occours.
Fatal Exception: java.lang.NumberFormatException: Invalid int: "z1 compact"
at java.lang.Integer.invalidInt(Integer.java:137)
at java.lang.Integer.parse(Integer.java:374)
at java.lang.Integer.parseInt(Integer.java:365)
at java.lang.Integer.parseInt(Integer.java:331)
at co.uk.rushorm.core.implementation.RushColumnInt.deserialize(RushColumnInt.java:22)
at co.uk.rushorm.core.implementation.RushColumnInt.deserialize(RushColumnInt.java:9)
at co.uk.rushorm.core.implementation.RushColumnsImplementation.setField(RushColumnsImplementation.java:50)
at co.uk.rushorm.core.implementation.ReflectionClassLoader.loadClass(ReflectionClassLoader.java:110)
at co.uk.rushorm.core.implementation.ReflectionClassLoader.loadClasses(ReflectionClassLoader.java:64)
at co.uk.rushorm.core.implementation.ReflectionClassLoader.loadClasses(ReflectionClassLoader.java:52)
at co.uk.rushorm.core.RushCore.load(RushCore.java:608)
at co.uk.rushorm.core.RushCore.load(RushCore.java:257)
at co.uk.rushorm.core.RushSearch.find(RushSearch.java:41)
Any other ideas? If we don't get rid of this strange bug, we have to change the database ORM..
Frustrating!!
Can you provide a % of crashes vs active installs and best list of effect devices with Android version.
Cheers
The Bug impact is on around 8% of the devices. Mostly samsung galaxy s5 with Android 4 & 5 HTC One, HTC One M8, and HTC One S and some Sony Xperia Z3 (compact) devices. All with Android 4 or 5 installed.
I tried to reproduce and fix this strange behaviour the whole day - and maybe i have a solution. When some users do not install all updates from playstore sequentially but update lets say from version 1 to 4 without changing the rush_db_version in manifest this exception is thrown. If every update is installed in correct order 1, 2, 3, 4 everything works fine... Not sure if this is really the bug, but it seems thats it is working now. We will release an update tomorrow and I'll keep u up2date if the error is gone.
Thanks for investigating this @fabsimilian , we also have the same problem. It happens across many devices and operating systems (Android 4,5,6)
If the migration only works step by step, we will also have to move to a different ORM unfortunately. I can see how this might be the case: Rush does not specify any migration steps, it does migration in one step, and depends on the current code base for knowing which columns to rename/migrate. So it can't properly migrate in some cases when too much has been changed between versions.