Fixed
Status Update
No update yet.
Comments
yb...@google.com
The generated dao code has this line:
_observer = new Observer("book","split")
I think annotation processor should handle this type usages of FROM clause.
I found a workaround for this problem. I created an unused entity named "Split" and it works.
_observer = new Observer("book","split")
I think annotation processor should handle this type usages of FROM clause.
I found a workaround for this problem. I created an unused entity named "Split" and it works.
Description
Version used: 1.0.0-alpha9
Currently the Configuration object encapsulates constant details about the DB (the version and callbacks) as well as the Context and filename required to actually open it. This means that when creating the machinery for a database, both the Callback instance and latest-supported version of that Callback need exposed. Then you hope that the consumer hooks both of them up correctly.
These two pieces of information are inherently linked, so it seems logical that the latest supported version could be moved inside the Callback via a 'int version()' method. This allows the Callback instance to become a constant whereas the filename and Context can be runtime-determined.
I'm also wondering if this obviates the need for the 'newVersion' parameter on both 'onUpgrade()' and 'onDowngrade()' methods, since the value returned from 'latestVersion()' could be used (or the constant that likely backs it).
Alternatively, the version could be added to the `Callback` constructor and exposed as a 'public final int version' field or 'int version()' method automatically.