Release 2.0 - 22 November 2010
This document discusses what's new in Ganymede 2.0, and what you'll need to think about if you are upgrading from an installation of Ganymede 1.0.
While Ganymede 2.0 is more similar to Ganymede 1.0 than it is different, the 2.0 series is the product of nearly ten years of development and refinement, and essentially every facet of the product has been refined, polished to a high shine, or at least tweaked, relative to the Ganymede 1.0 releases.
The major functional differences between the Ganymede 1.0 series and Ganymede 2.0 are as follows:
For a comprehensive list of changes in the 2.0 release, please see the CHANGES file. You should be especially sure to consult this file if you have any previous programming experience with the Ganymede framework, as a good number of minor changes have accumulated over the last few years.
A number of fields have been renamed since Ganymede 1.0. These renames should be handled automatically for you if you try to load a Ganymede 1.0 series database file with a Ganymede 2.0 server, but if you are doing XML loading, you may need to be aware of the following name changes:
Object | Field Number | Field Type | Old Field Name | New Field Name |
---|---|---|---|---|
System Event | 103 | boolean | Event Mail | Send Mail |
System Event | 106 | boolean | Cc Owner Groups | Cc Owners |
Owner Group | 105 | string | Mail List | External Mail List |
Role | 101 | permission matrix | Owned Object Bits | Objects Owned Access Bits |
Role | 103 | permission matrix | Default Bits | Default Access Bits |
If you have a Ganymede 1.x schema that does not force unique labels on all object types, Ganymede 2.0 will give you a warning when you go to load your old ganymede.db file. If you bring up the Ganymede schema editor or use the xmlclient to tweak the schema, no changes will accepted to your schema until you resolve the unique label issue.
The Objects Owned Invid field in the Owner Group object has been removed. This change makes it possible for multiple administrators to create objects in a common Owner Group without experiencing lock-out. This will again be handled for you automatically if you load a Ganymede 1.0 db file, but if you are working with XML, you may need be aware of this, particularly when loading Permission Matrix dumps.
If you have custom plugin classes written against Ganymede 1.0, you will absolutely need to make some changes in order to get your classes working properly in Ganymede 2.0.
The most elementary change is that classes in the Ganymede server have been shuffled around to different packages for clarity in the source tree and build process. You will need to make sure you use arlut.csd.ganymede.common for classes that are used on the server and on the client, arlut.csd.ganymede.rmi for RMI interfaces, and arlut.csd.ganymede.server for the classes that uniquely comprise the Ganymede server.
A wide variety of methods in several classes in the Ganymede server now throw an arlut.csd.ganymede.common.GanyPermissionException when permission problems are encountered. This is a checked exception, so you may need to modify your code to handle this exception intelligently.
The DBEditObject 'deleting' boolean has been made private. You'll need to use the DBEditObject.isDeleting() method to test the deleting status of an editable object.
Otherwise, I believe the classes you'll use in writing your own plugin subclasses for DBEditObject and GanymedeBuilder shouldn't need a great deal of changes. Most of the other method changes have been done in a backwards compatible fashion.
If you're writing a new set of plugin classes, you may find that there are some more convenient methods to use when writing your custom logic than were available in the 1.x time frame. For instance, many methods that deal with fields allow you to look up or address fields by their display name, rather than having to use numeric codes. Be aware that if you use the name-based methods, you will make it difficult for yourself if you want to produce a version of your schema kit in other languages, however.
Vector fields can no longer hold duplicates. This was implicit in some of the code before, it is now explicit. If you attempt to load an old ganymede.db file that includes duplicate values in a Vector field, the system will allow the duplication, and this can surprise some code.
So, beware. When in doubt, use xmlclient in your Ganymede 1.x installation to dump your data to disk, examine for duplicates, and reload into your 2.x installation using the xmlclient.