Jan S Berg wrote: > > Hi, > > we have made a draft ARC case for integrating 64bit MySQL and the ODBC > and JDBC Connectors to OpenSolaris:
> MySQL 32 bit server,clients and c-api with man pages and testsuites has > already been integrated into OpenSolaris. > > With this Fasttrack we want to integrate also 64 bit binaries and libraries > into OpenSolaris. We also want to integrate the JDBC and ODBC Connectors. I guess it can be assumed, but I'd update the above to be clearer that this is delivering both 32bit and 64bit connectors, in addition to 64bit versions of all the previously delivered parts. Please add somewhere (maybe right in section 2.3 if it is only a few items, or as an Appedix if it is a very long list) the set of all new files being delivered by this case. Right now it's a bit vague. Some minor nits in the location wording that should help clarify: > /usr/mysql/5.0 > /bin adding ODBC binaries I'd say "32bit ODBC binaries will be added here" to be more descriptive. > /bin/64 softlink to appropriate 64 bit binaries "softlink to appropriate 64 bit directory" > /bin/amd64 amd only 64bit binaries > /bin/sparcv9 sparc only 64bit binaries > /lib adding ODBC libraries 32bit as before > /lib/64 softlink to appropriate 64 bit libraries "directory", as before > /lib/amd64 amd only 64bit libraries > /lib/sparcv9 sparc only 64bit libraries > /jdbc JDBC Driver > 2.4 SMF > > We will use the already delivered smf metafile as well as a > smf startup script. We will add a property to the smf service > for choosing between 32 and 64 bit. Default will be the architecture > you are running on. What's the name of the new property? List it in the exported interface table as well. Is 64bit overwhelmingly always the better choice when running on a 64bit platform? (Enough so that it should be the default?) > 3. MySQL Documentation > > No changes to the existing documentation. That doesn't sound right? There's new things here which need documentation. The man page(s) need to be updated to cover the 64bit support (and smf property). Presumably the ODBC & JDBC connectors have some sort of documentation as well? > 4. Packaging and Delivery > > We propose to have the MySQL 64bit and connectors under the > following packages: Again for more clarity, I suggest making explicit which packages are new here and which ones are existing packages that will include new files (while I know the answer, not every reader of the ARC case necessarily will..) > SUNWmysql5u - [usr] Server package (adding 64 bit binaries/libraries) > SUNWmysql5r - [root] (add 64 bit data directory/configs) > SUNWmysql5j - JDBC Connector > SUNWmysql35o - ODBC Connector > > Multiple versions can coexist, and are distinguished by the > version (5 for version 5.0.*). The ODBC driver is version 3.51.x > and does not follow the usual MySQL version numbering. How does SUNWmysql35o relate to the version of MySQL installed? In the future when I install SUNmysql6 can I just install SUNWmysql35o to get ODBC connector support for it? How would I know? Or is SUNWmysql35o tightly coupled with MySQL5? What are the package dependencies? > 5.2. Imported Interfaces > > MySQL 64bit and connectors imports and make use of interfaces from > > NAME STABILITY NOTES > UnixODBC Standard LSARC/2007/684 > Java Standard PSARC/2003/696 > MySQL 5.0 Standard LSARC/2007/608 >From a quick scan, neither LSARC/2007/608 or LSARC/2007/684 exports anything as "Standard", so that must be wrong. PSARC/2003/696 has a couple standard exports but they don't seem to match your import (though "Java" is so generic). So to clarify, when a case imports an interface, it is a link to some other case which exported that same interface. The stability can only be what the original case declared it to be. Please double check the 3 cases from which this case is importing, identify the line item in their Exported Interface table that this case is importing and reference them here as Imported using the same stability as defined there. > 5.3. Exported Interfaces > > NAME STABILITY NOTES > svc:/application/database/mysql:version_50 > Committed FMRI > /lib/svc/method/mysql Project Private SMF service method script > /var/svc/manifest/application/database/mysql.xml > Project Private SMF Manifest These 3 show up in LSARC/2007/608 as well and seem identical. Is there something different about what this case exports? Also please add the SMF property name to the exported table. Martin MC Brown wrote: > > All the current major storage engines (with one exception) are > architecture neutral, both in endian-ness and bit size. You should be > able to copy a 64-bit or 32-bit DB either way, and even between > platforms without problems for MyISAM, InnoDB and NDB. For other > engines it doesn't matter (CSV, MEMORY, MERGE, BLACKHOLE and > FEDERATED) either don't have a disk storage format or the format they > use is test based (CSV) or based on MyISAM (and therefore not an issue). > > The current exception for the current releases is Falcon which is, for > the moment, unsupported on non-x86 architectures (although partial > support is due for the 6.0.4 release and there re further improvements > for the release after that (particularly on SPARC and PowerPC). > However, AFAIK there is currently no migration support between > platforms - you have to dump and reload a Falcon database. > > In practice, we generally recommend a dump and reload for absolute > compatibility for any engine and major migration such as this... > > Since we are talking about the 6.x release series, that doesn't affect > us now, but I'm merely offering it up for information :) This is valuable info, I recommend summarizing it in the case somewhere for the record. -- Jyri J. Virkki - jyri.virkki at sun.com - Sun Microsystems
