| Title: Upgrade |
| |
| <H3><A name="Upgrade-GeneralUpgradeRecommendations"></A>General Upgrade Recommendations</H3> |
| |
| <UL> |
| <LI>Consult <TT>UPGRADE.txt</TT> and <TT>RELEASE-NOTES.txt</TT> files in the release you just downloaded for the most up to date instructions.</LI> |
| </UL> |
| |
| |
| <UL> |
| <LI><EM>(Optional)</EM> Delete CayenneModeler preferences. This is not strictly required, but recommended (especially if you used intermediate milestones and Betas). To do that delete "$HOME/.cayenne/modeler.preferences" file and "$HOME/.cayenne/prefs" directory, where <TT>$HOME</TT> is a user home directory which is OS and machine specific.</LI> |
| </UL> |
| |
| |
| <UL> |
| <LI>Upgrade Cayenne Mapping Projects. Open your project with the version of the Modeler that came with the latest download. If an upgrade dialog pops up, select "yes" to do an upgrade. Also it is also a good idea to make some insignificant change to the model (so that a "Save" button is activated) and do a save.</LI> |
| </UL> |
| |
| |
| <DIV class="panelMacro"><TABLE class="warningMacro"><COLGROUP><COL width="24"><COL></COLGROUP><TR><TD valign="top"><IMG src="http://cayenne.apache.org/docs/3.0/images/icons/emoticons/forbidden.gif" width="16" height="16" align="absmiddle" alt="" border="0"></TD><TD>Upgrading project XML files can make them unusable with earlier versions of Cayenne.</TD></TR></TABLE></DIV> |
| |
| <UL> |
| <LI>Pay attention to CayenneModeler validation warnings.</LI> |
| </UL> |
| |
| |
| <UL> |
| <LI>Do a clean recomplie. Recompile all your code, to make sure that you are not using any old classes or methods. Pay attention to deprecation warnings. It is always a good idea to update your code to avoid deprecated API.</LI> |
| </UL> |
| |
| |
| <H3><A name="Upgrade-Upgradingto3.0"></A>Upgrading to 3.0</H3> |
| |
| <UL> |
| <LI>If you are still using ObjectStyle.org releases of Cayenne, read "Upgrading to 2.0" for the information on how to change the package names.</LI> |
| </UL> |
| |
| |
| <UL> |
| <LI>Java 5 is now required as a minimum for Cayenne Modeler and the Cayenne libraries.</LI> |
| </UL> |
| |
| |
| <UL> |
| <LI>After the move to Java 5, generics have been implemented in many of the Cayenne APIs. If you don't use generics in your project this should not affect you, but if you do you will need to review any new compiler errors or warnings. The effect of generics is at compile time only, so their introduction will not change the runtime behaviour of your application once compiled.</LI> |
| </UL> |
| |
| |
| <UL> |
| <LI>Jar files: |
| <UL> |
| <LI>all jar files now include version numbers in their names.</LI> |
| <LI>"cayenne-nodeps.jar" is renamed to "cayenne-server-x.x.x.jar"</LI> |
| <LI>"fat" cayenne.jar file that included dependencies is no longer distributed. All dependencies that it contained are included as separate jars under "cayenne-x.x.x/lib/third-party/". The new "cayenne-server-x.x.x.jar" plus dependencies should be used in place of cayenne.jar.</LI> |
| <LI>A new "cayenne-agent-x.x.x.jar" is included. It is used for class enhancement with POJO's and JPA. "Classic" Cayenne users can ignore this file.</LI> |
| </UL> |
| </LI> |
| </UL> |
| |
| |
| <UL> |
| <LI>Ant class generator is using what was called "version 1.2" by default. This means that if you were<BR> |
| using custom Velocity templates in 1.1 mode, you should either change the templates or specify 'version="1.1"'<BR> |
| in the buildfile explicitly.</LI> |
| </UL> |
| |
| |
| <UL> |
| <LI>Cross-platform Modeler Startup is now done without a batch file or a shell script.<BR> |
| A "fat" CayenneModeler.jar is included in the "cayenne-x.x.x/bin" directory<BR> |
| and can be run either by double-clicking the jar (on platforms that support that)<BR> |
| or by running "java -jar CayenneModeler.jar".</LI> |
| </UL> |
| |
| |
| <UL> |
| <LI>FireBird adapter is no longer distributed with Cayenne. The one we had was half-working<BR> |
| and we could not support it anymore.</LI> |
| </UL> |
| |
| |
| <UL> |
| <LI>DerivedDbEntities are removed from Cayenne.</LI> |
| </UL> |
| |
| |
| <UL> |
| <LI>DVModeler and DataViews are no longer shipped with Cayenne. See <A href="http://cwiki.apache.org/CAYDV/" class="external-link" rel="nofollow">http://cwiki.apache.org/CAYDV/</A> for more details.</LI> |
| </UL> |
| |
| |
| <UL> |
| <LI>DataContextTransactionEventListener, DataObjectTransactionEventListener, DataContextEvent are removed.</LI> |
| </UL> |
| |
| |
| <UL> |
| <LI>Long PK: Cayenne now supports "long" primary key generation (previously it only supported "int"). You may<BR> |
| have to change the existing PK lookup tables on some databases to take advantage of that (this is optional,<BR> |
| and is needed if you expect your PK to exceed maximum value of an "int" allowed in your database). E.g. on <BR> |
| MySQL you may run the following SQL:</LI> |
| </UL> |
| |
| |
| <DIV class="code panel" style="border-width: 1px;"><DIV class="codeContent panelContent"> |
| <PRE class="code-java">ALTER TABLE AUTO_PK_SUPPORT CHANGE COLUMN NEXT_ID NEXT_ID BIGINT NOT NULL;</PRE> |
| </DIV></DIV> |
| |
| |
| <H3><A name="Upgrade-Upgradingto2.0"></A>Upgrading to 2.0</H3> |
| |
| <P>2.0 is a mirror of 1.2 (third digit in release number is a patch level that matches 1.2 version, e.g. "2.0.1" has the same patch level as "1.2.1"). The main change is that all packages were renamed from "org.objectstyle.cayenne*" to "org.apache.cayenne.*". This affects user API and also mapping XML files (as they sometimes reference Cayenne classes by name).</P> |
| |
| <UL> |
| <LI>First you need to upgrade the mapping files as described in general upgrade instructions above.</LI> |
| </UL> |
| |
| |
| <UL> |
| <LI>Upgrading the code: Replace "org.objectstyle.cayenne" with "org.apache.cayenne" everywhere in imports and do a clean recompile.</LI> |
| </UL> |
| |
| |
| <UL> |
| <LI>Upgrading logging configuration: If you are using custom logging configuration file, make sure that all the Cayenne loggers are changed from "org.objectstyle.cayene" to "org.apache.cayenne".</LI> |
| </UL> |
| |
| |
| |
| <H3><A name="Upgrade-Upgradingto1.2"></A>Upgrading to 1.2</H3> |
| |
| <P>This is the list of things that are different in 1.2 and may require attention when doing an upgrade:</P> |
| |
| <UL> |
| <LI>Cayenne tools and runtime now REQUIRE at least JDK 1.4 (or higher). They won't work on JDK 1.3. If you are still on 1.3, upgrade your JDK if you can. If you can not, consider staying on Cayenne 1.1.</LI> |
| </UL> |
| |
| |
| <UL> |
| <LI>1.2 no longer needs Jakarta BeanUtils.</LI> |
| </UL> |
| |
| |
| <UL> |
| <LI>1.2 no longer relies on ClassLoader provided by Configuration (this API is deprecated as a matter of fact). Current code uses Thread.currentThread().getContextClassLoader().</LI> |
| </UL> |
| |
| |
| <UL> |
| <LI>In 1.2 PostgreSQLAdapter uses DB sequences for primary key generation instead of AUTO_PK_TABLE. To port an existing application, you will need to create those sequences (e.g. using the Modeler) and assign correct current values to them (e.g. taken from the old AUTO_PK_TABLE). After that AUTO_PK_TABLE can be dropped.</LI> |
| </UL> |
| |
| |
| <UL> |
| <LI>In 1.2 PostgreSQLAdapter's default "BLOB" mapping is changed from "bytea" to "oid". It is still possible to use bytea, but watch for the Modeler-generated schema scripts - they will contain "oid". The easiest way to migrate your mapping (if you don't want to change the DB) is to remap all bytea columns as LONGVARBINARY DbAttributes instead of BLOB.</LI> |
| </UL> |
| |
| |
| <UL> |
| <LI>For extra portability encoding of entity type in the ObjectId is now based on ObjEntity name, not Java class as before. If you had ObjEntities with matching names but different class names in different DataMaps, you will need to ensure entity name uniqueness.</LI> |
| </UL> |
| |
| |
| <UL> |
| <LI>ObjectId methods "getObjClass" and "getObjectClass" are removed (it wasn't possible to deprecate them and still preserve meaningful functionality). Constructors that take Class as the first argument are deprecated and will only work if entity naming follows CayenneModeler default conventions of using unqualified class name as the entity name.</LI> |
| </UL> |
| |
| |
| <UL> |
| <LI>TempObjectId is deprecated and is no longer used by Cayenne internally. If you were referencing TempObjectId explicitly in your code (e.g. if(id instanceof TempObjectId) ... ), you will need to modify the code and use "isTemporary()" superclass method.</LI> |
| </UL> |
| |
| |
| <UL> |
| <LI>The meaning of SnapshotEvent "source" and "postedBy" attributes is reversed per CAY-395 for better efficiency. If you implemented custom listeners of SnapshotEvents, you may need to doublecheck their logic. From now on events use DataRowStore as source, and EventBridge or ObjectStore as postedBy, depending on whether this was a local or a remote event. I.e. the new structure is the opposite to what we used in 1.1.</LI> |
| </UL> |
| |
| |
| <UL> |
| <LI>Cayenne stack events are no longer sent via a shared "default" EventManager. If you were using EventManager.getDefaultManager() to communicate or receive Cayenne stack events, you'll have to switch to Configuration.getEventManager(). Otherwise default manager can be accessed as before.</LI> |
| </UL> |
| |
| |
| <UL> |
| <LI>Query.setLoggingLevel/getLoggingLevel methods are removed from the interface and AbstractQuery implementor. As multi-tier Cayenne doesn't use Log4J, it was no longer possible to keep these methods deprecated.</LI> |
| </UL> |
| |
| |
| <UL> |
| <LI>Thread-bound Transactions: QueryEngine.performQueries(Collection,OperationObserver resultConsumer,Transaction) is deprecated and no longer used internally to further decouple layers in the access stack. This DOES NOT AFFECT most users. Only if you (a) implemented custom transactions and (b) manually manage their commit/rollback, you will also have to bind and unbind such Transactions to the current thread manually, for Cayenne stack classes to pick them up.</LI> |
| </UL> |
| |
| |
| <UL> |
| <LI>To force refresh of cached query results, one of the two new cache policies should be used instead of "setRefreshingObjects(..)" ("setRefreshingObjects" should only be used for its original purpose - refreshing individual objects, not list contents). See <A href="caching-query-results.html" title="Caching Query Results">Caching Query Results</A> for details.</LI> |
| </UL> |
| |
| |
| <UL> |
| <LI>ObjectStore no longer stores database snapshots of object. As a result a method "retainSnapshot(DataObject object)" is removed, as its meaningful deprecation is not possible.</LI> |
| </UL> |
| |
