Martin MC Brown wrote:
>
>>>>>
>>>>> 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
Yes, that is a good idea.

>
>>
>>> 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.
Thanks for the clarification, but that's why I wrote "same" :)
My point is that a later driver probably will be a better match with a 
later server with respect to functionality.

>
>> 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 :)
ok, I see your point :)
>
> 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.
Thanks, will update with your suggestions

Jan S


Reply via email to