>>>> >>>> But where on the filesystem does SUNWmysql35o deliver its content >>>> (this is why it's useful to have some listing or Appendix showing >>>> what each package delivers)? >>>> >>> It will be listed under the 5.0 release, but to use the Connector/ >>> ODBC >>> you will specify how to connect to the server using >>> odbc.ini/odbcinst.ini files and should not be depending on which >>> version >>> you are running. >>> >> >> By listed do you mean in terms of filesystem location? >> > Yes, it would be under /usr/mysql/5.0/
Hmmm - can't we put it under /usr/mysql/codbc or similar? For future compatibility (And support for the other connectors), why not have a structure: /usr/mysql/connectors Under which we could include: /usr/mysql/connectors/odbc/3.35 /usr/mysql/connectors/odbc/5.1 /usr/mysql/connectors/java/5.1 > >> The >> main question I'm chasing is how closely are these two (MySQL5 and >> mysql35o) related. The relationship manifests itself in several ways >> and those ways should be consistent. One is package naming, other is >> package dependencies, other is file layout and yet another is actual >> runtime dependencies. >> >> If these two are functionally entirely independent, it seems odd if >> the ODBC driver installs under /usr/mysql/5.0/lib (I don't know where >> yet, waiting for the appendix info ;-). That would mean that in the >> future if I install only MySQL6 and SUNWmysql35o I end up with a >> fully >> populated /usr/mysql/6.0/* and solitary ODBC files under /usr/mysql/ >> 5.0/lib? >> > That is correct, but the point is that even SUNWmysql35o is working > using the MySQL6 server, it is always the > recommendation to use the "same" version of the driver. Er, do you mean that the recommendation is to use the same version of the driver and MySQL version? If that's the case, then that advice is wrong. We thought about matching drivers and MySQL versions a while back, but never followed through because the different connector versions and server would never match. The release cycle of the server is currently 4-5 years. Keeping the versions numbers in sync for the connectors would mean major new features and updates couldn't have a recognizable major version number. As such, the similarity between version numbers is a combination of pure coincidence and the stalled attempt to synchronize things. In short, no connector version is targeted to work with a specific MySQL version, and you certainly shouldn't aim to match numbers. At best you should use the latest GA version for each item. If it helps, both C/J and C/NET have a 5.2 version on their way, even though they will be designed to work with MySQL from 4.1 through to 6.0. If there's anyway in the documentation that leads you to believe otherwise, let me know and I'll fix. > The problem here > is that the ODBC driver version is 3.51.23, > while the server version is 5.0, while for the upcomming MySQL 5.1 > server the ODBC Connector will also have version 5.1 Here is a good example why you shouldn't match numbers :) C/ODBC 5.1 is a complete rewrite of the 3.51.x tree, but it is ultimately designed to be basically compatible with the 3.51.x functionality, plus some additional new features, such as native Unicode and improved data and installers. Otherwise, there are no differences in terms of the server versions supported. As a side note, C/ODBC 5.1 will shortly be GA (we had second beta release last week). We are still fixing bugs in 3.51.x, but not supporting any major new features (the only recent significant feature for 3.51.x were some improvements to the interface and SSL support). >> If SUNWmysql35o installs under /usr/mysql/5.0/* it probably should >> have a package dependency on MySQL5 and should even be named in some >> representative way (don't know, maybe SUNWmysql5-odbc or some such). >> On the other hand if it is entirely independent then it probably >> shouldn't install under /usr/mysql/5.0/ at all, but elsewhere. >> Maybe a >> /usr/mysql/common/? >> > I guess for clarity we can have the packagename SUNWmysql5odbc for > this > release. > > And btw, you can always install only the ODBC package without the > server, on a client machine f.ex. Yep - there is no dependency on C/ODBC and the server (C/ODBC talks native protocol to MySQL over network/socket, exposing that interface through ODBC). Another good reason for a more flexible directory structure. MC -- Martin 'MC' Brown, mc at mcslp.com Everything MCslp: http://planet.mcslp.com
