Fwd: Re: libmysqlclient so version

2013-08-06 Thread rafal somla

Forwarding my reply here, as it might be interesting to other people too.


 Original Message 
Subject: Re: libmysqlclient so version
Date: Mon, 05 Aug 2013 14:10:28 +0200
From: rafal somla rafal.so...@oracle.com
Organization: Oracle Corporation
To: Sebastien FLAESCH s...@4js.com

Hello Sebastien,

Thank you for your interest in our latest MySQL server release.


On 07/31/2013 01:03 PM, Sunanda Menon wrote:

  * The C API libmysqlclient shared-library .so files now have
version 18.1.0 (up from version 18.0.0 used in MySQL 5.5).
(Bug #16809055)


What impact has this change regarding backward compatibility with
existing C programs linked to older 5.6 libmysqlclient.so libs and
what is the general policy regarding the backward compatibility for
this library - where can we find clear statements in the doc?

Does it make sense to change the .so version in a bug fix release,
when the 5.6 was already releases as GA?

We are providing database drivers for MySQL in our development tool.
We have a C shared library linked to libmysqlclient.so, and we have
to link it with the correct 5.6 library version.
What solution would you recommend, if you change the .so version
number in MySQL 5.6 upgrade / bug fix releases?


Although we changed the minor library version in 5.6.13, it should be
fully backward compatible with previous versions and code using the
library should work without any problems. In particular, any code which
links against libmysqlclient.so depends on libmysqlclient.so.18 (note
that the minor version number is not present in the soname). Version
18.1.0 of the library installs with a symbolic link libmysqlclient.so.18
- libmysqlclient.so.18.1.0. Thus we expect all applications to work as
before after upgrading to MySQL 5.6.13.

Please let us know if it does not work for you.

With Best Regards,

Rafal Somla,
Senior Software Developer @ MySQL/Oracle



--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/mysql



Re: libmysqlclient so version

2013-08-06 Thread rafal somla

Hello again!

On 2013-08-05 15:07, Sebastien FLAESCH wrote:

Hello Rafal and thank you for you answer.

Note I sent a similar mail in the mailing list. So I think you should
also answer in the mailing list too.

I understand that it should be ok regarding
libmysqlclient.so.18.1.0.

$ ldd -r
/home/sf/genero/devel/fgl/fgl/opt/fgl/dbdrivers/dbmmys55x.so 
libmysqlclient.so.18 = /opt3/dbs/mys/5.6.10/lib/libmysqlclient.so.18
(0xb7298000)

If I may ask you something that would help me a lot:

We have an internal debate, where some argue that we could have a
unique binary linked to libmysqlclient.so, that could work for all
MySQL versions, for example for all 5.x versions.

While it appears that 5.5.x and 5.6.x libraries are compatible (since
the major version number (18) of the lib did not change), my instinct
is that we should produce one specific binary for each major MySQL
version we want to support (i.e 4.1.x, 5.0.x, 5.1.x, 5.4.x, 5.5.x,
5.6.x) ...

We need a clear rule...!! For example with Oracle database, we have a
binary for each major version of Oracle (9.0.x, 9.2.x, 10.1.x,
10.2.x, 11.1.x, 11.2.x, 12.1.x)

I asked for a clear compatibility statement in the doc...

If you could state that it's STRONGLY recommended to link C binaries
with a libmysqlclient.so.num version for each major MySQL, it
would help me to define a clear rule for our product...



In general we strive to keep the library backward compatible - as long
as the major version of the library is the same, it should be safe to
use the library with old applications. You should care about minor
version only if you want to use some new API calls introduced in later
release of the library. I think the best practice would be to check
which release of the library is used at runtime (using
mysql_client_version() API call) and then either make use of new
features conditional on this version check or error-out if library is
not recent enough

The major version of libmysqlclient library is not tied to a particular
version of MySQL server. It rather reflects changes in the C API itself.
Thus it is quite possible that two different versions of MySQL server
offer the same version 18.X of the client library with the same
functionality, but perhaps the newer version contains bug fixes or
improvements in the implementation of this functionality.

Thus I do not see a need to produce new version of binaries for each new
released version of MySQL server. Rather, you should re-compile your
applications only if either:

a) you want to use new C API features introduced in the new release, or

b) we introduce incompatible change in C API and thus increase its major
version number (e.g from 18.X to 19.0). In that case new binaries will
look for libmysqlclient.so.19 while old ones will still use
libmysqlclient.so.18.

Note that even without re-compiling your apps, if you upgrade your MySQL
installation then new version of libmysqlcient.so will be installed on
your system and picked up by the dynamic linker. So your application
will take benefit of bug fixes and other improvements in C API
implementation.

Best Regards,
Rafal



Best regards, Sebastien FLAESCH Four JS Development Tools

On 08/05/2013 02:10 PM, rafal somla wrote:

Hello Sebastien,

Thank you for your interest in our latest MySQL server release.


On 07/31/2013 01:03 PM, Sunanda Menon wrote:

* The C API libmysqlclient shared-library .so files now have
version 18.1.0 (up from version 18.0.0 used in MySQL 5.5). (Bug
#16809055)


What impact has this change regarding backward compatibility
with existing C programs linked to older 5.6 libmysqlclient.so
libs and what is the general policy regarding the backward
compatibility for this library - where can we find clear
statements in the doc?

Does it make sense to change the .so version in a bug fix
release, when the 5.6 was already releases as GA?

We are providing database drivers for MySQL in our development
tool. We have a C shared library linked to libmysqlclient.so, and
we have to link it with the correct 5.6 library version. What
solution would you recommend, if you change the .so version
number in MySQL 5.6 upgrade / bug fix releases?


Although we changed the minor library version in 5.6.13, it should
be fully backward compatible with previous versions and code using
the library should work without any problems. In particular, any
code which links against libmysqlclient.so depends on
libmysqlclient.so.18 (note that the minor version number is not
present in the soname). Version 18.1.0 of the library installs with
a symbolic link libmysqlclient.so.18 - libmysqlclient.so.18.1.0.
Thus we expect all applications to work as before after upgrading
to MySQL 5.6.13.

Please let us know if it does not work for you.

With Best Regards,

Rafal Somla, Senior Software Developer @ MySQL/Oracle





--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/mysql



com.mysql.jdbc.MysqlDataTruncation: Data truncation: Data too long for column 'DATA_COLUMN' at row 1

2013-08-06 Thread Ravi Gupta
I am using the largest datatype I can, LONGTEXT or LONGBLOB,
and still get the above, the data can't be that large, so I have no idea.
  property name=dataColumnType value=LONGTEXT/


-- 
Ravi Gupta 

Solutions Architect 
JBoss by Red Hat, Inc. 

Email: rgu...@redhat.com | c: 773.544.6894 | http://www.redhat.com 


-- 
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/mysql