upgrade notes for version 4.37 Android added in retrospect
Gray Watson
A bug fix made in 4.37 introduced an incompatibility under Android with mismatched column-name case between the Java field and the database. I have made a decision to _not_ fix this incompatibility and to keep the case sensitivity since there are other parts of ORMLite which are also case sensitive with regards to field names. I've added these upgrade notes for version 4.37 in retrospect.
If you have a field in your Android SQLite that is named 'accountname' but the Java field is 'accountName' then as of 4.37 you will get an exception when you query for that object.
java.sql.SQLException: Unknown field 'accountName' from the Android sqlite cursor, not in:[accountname, ...]"
To fix it, you will need to use the @DatabaseField(columnName = "accountname") annotation field:
@DatabaseField(columnName = "accountname")
private String accountName;
Sorry for the confusion on this and sorry for the backwards incompatibility. Although painful for some folks to upgrade, I feel it is the right thing to do.
Thanks much to Roman Zimmer for bringing this to my attention.
gray
jc
>
> ...incompatibility under Android with mismatched column-name case between the Java field and the database....
>
I thought this statement meant that the GENERATED database field name
does not match the case of the Java field in earlier versions and that
it would impact everyone who upgrades on Android. I read the upgrade
notes again and the example implies this as well, but after upgrading
it appears as if the generated database field names from prior
versions DO match the java field names and that this incompatibility
will only impact those who may have renamed or forced their column
names to be different or have mismatched case in queries.
Prior to 4.37, if the java field name is "accountName", ORMLite
generated the field as "accountName" but you could query for
"accountName" or "accountname" without errors.
In 4.37, if the java field name is "accountName", the actual database
field name is still "accountName"; however, you must query for
"accountName" only and "accountname" will not work unless you use the
annotation to override this.
Based on my upgrade, it appears that if you used ORMLite generated
column names based on the java field name and were consistent with
your column names in any query builders, you shouldn't have any
backwards compatibility issues with the upgrade.
Gray, can you confirm this for anyone else who may have misinterpreted
this as I did and might be worried about the upgrade?
Gray Watson
> Gray, can you confirm this for anyone else who may have misinterpreted
> this as I did and might be worried about the upgrade?
I can certainly confirm this. Sorry for the confusion. I will expand the 4.37 release notes.
thanks JC,
gray
Gray Watson
There was some confusion so let me be clear that this is _only_ if you already have mismatched between your database fields and your Java under Android SQLite. If you used ORMLite to create your schema _or_ if you used @DatabaseField(columnName = ...) to make your case match then you would not see this issue.
This only would affect people who were working with an _existing_ database whose fields did not match the Java. The Android API was looking up fields in a case insensitive manner so was masking problems with this.
I've reposted the Upgrade documentation which hopefully is more clear:
gray
James Morgan
James
Gray Watson
> So is the best option to take to simply fully qualify the field name for all columns. This will mean that the case sensitivity issue will not arise in the future i.e. always specifying the column name with annotated fields. @DatabaseField(columnName = ...)
No, that _really_ is not necessary. If the field-name is accountName then the database field should match exactly. Only if the field name does _not_ .equals the database field name do you have to worry about it.
gray
Roger Keays
Gray Watson
gray
> You received this message because you are subscribed to the Google Groups "ORMLite Android Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to ormlite-andro...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
Roger Keays
Undoubtedly I'll be revisiting the problem so I'll attach a stack trace
next time :)
Roger Keays
Robolectric test so I'm wondering if it is converting the column names
to lowercase.
java.sql.SQLException: Unknown field 'ordinalGroup' from the Android sqlite cursor, not in:[ordinal, ordinalgroup, id]
at com.j256.ormlite.android.AndroidDatabaseResults.findColumn(AndroidDatabaseResults.java:128)
at com.j256.ormlite.field.FieldType.resultToJava(FieldType.java:815)
at com.j256.ormlite.stmt.mapped.BaseMappedQuery.mapRow(BaseMappedQuery.java:60)
at com.j256.ormlite.stmt.StatementExecutor.queryForFirst(StatementExecutor.java:99)
at com.j256.ormlite.dao.BaseDaoImpl.queryForFirst(BaseDaoImpl.java:233)
at com.j256.ormlite.stmt.QueryBuilder.queryForFirst(QueryBuilder.java:375)
at au.com.ninthavenue.patterns.android.hierarchy.BaseOrdinalDAO.setMaxOrdinal(BaseOrdinalDAO.java:189)
at au.com.ninthavenue.patterns.android.hierarchy.BaseOrdinalDAO.create(BaseOrdinalDAO.java:34)
at au.com.ninthavenue.patterns.android.hierarchy.BaseOrdinalDAO.create(BaseOrdinalDAO.java:24)
at au.com.ninthavenue.patterns.android.base.BaseDAO.save(BaseDAO.java:45)
at au.com.ninthavenue.patterns.android.hierarchy.BaseOrdinalDAO$DeleteTest.$_sibling_ordinals_are_reset
(BaseOrdinalDAO.java:162)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at com.xtremelabs.robolectric.RobolectricTestRunner$1.evaluate(RobolectricTestRunner.java:292)
at org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(BlockJUnit4ClassRunner.java:79)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:71)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:49)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:236)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:134)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:113)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:103)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)
On Thursday, 04 September, 2014 12:50 AM, Gray Watson wrote:
Roger Keays
This seems to be a Robolectric compatibilty problem:
https://github.com/robolectric/robolectric/issues/1017
AFAICT it is fixed in Robolectric 2.3