Hi Jyri, Jyri Virkki wrote: > 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. > Yes, Connector/ODBC will also be in 64 bit. No difference for the Connector/J since it's all Java. > > > 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. > ok, will add the files for Connector/J and Connector/ODBC, for the 64bit it will be the same files as delivered by the 32bit case, so I guess that does not need to be repeated? Will state that all binary and library files delivered in 32 bit will also be delivered in 64bit. > > 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. > Will update with this > >> /bin/64 softlink to appropriate 64 bit binaries >> > > "softlink to appropriate 64 bit directory" > Will do > >> /bin/amd64 amd only 64bit binaries >> /bin/sparcv9 sparc only 64bit binaries >> /lib adding ODBC libraries >> > > 32bit as before > Will do > >> /lib/64 softlink to appropriate 64 bit libraries >> > > "directory", as before > Will do > >> /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. > We are proposing to call it "arch", but if there is a standard way of naming this we would like to use that, although haven't found any. > Is 64bit overwhelmingly always the better choice when running on a > 64bit platform? (Enough so that it should be the default?) > I have not been running that much performance testing with MySQL 32 vs 64, but from experience with other databases it is not always the best choice. It was pointed out by Peter in this thread that 64bit version on x86 was mostly the better choice. There is no good way of predicting which should be 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? > Yes, sorry, should be adding doc for JDBC and ODBC Connectors as well as how to setup 64bit. > >> 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..) > ok, will update this. And also the SUNWmysql5r package will not be affected, since we are not delivering new configs and data directories, so it will be removed from this onepager. > >> 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? > To my knowledge it should work with different versions of MySQL server. > In the future when I install SUNmysql6 can I just install SUNWmysql35o > to get ODBC connector support for it? How would I know? > Unless there are significant changes in the communication protocol, it should be compatible. But there will be new versions of the ODBC Connector (the version 5.1 is already in beta), and you might not be able to use new functionality introduced in newer versions (ie post 5.0) of MySQL server. When we add newer versions of the MySQL server we should also upgrade to latest drivers. > Or is SUNWmysql35o tightly coupled with MySQL5? What are the package > dependencies? > Not tightly coupled with MySQL5, but are depending on the unixODBC driver manager package, as stated in the interface section. > >> 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. > Ok, will update the stability to: UnixODBC - Uncommited MySQL 5.0 - Commited/Project Private
And I think it is better to remove Java, and state that the driver implements JSR 221 (JDBC version 4), which is more correct. It is also what is done for other JDBC drivers (PostgreSQL and JavaDB), they don't refer to Java ARC cases. Is that ok? > >> 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. > Yes, will state that we add the "arch" property to the FMRI, and remove the service method script and SMF Manifest as these interfaces will not change. > > 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. > ok, will add this to the technical section. Thanks for the comments! Jan S
