[MDEV-7419] Function cli_safe_read not exported Created: 2015-01-08  Updated: 2015-02-18  Resolved: 2015-02-13

Status: Closed
Project: MariaDB Server
Component/s: Compiling
Affects Version/s: None
Fix Version/s: 5.5.42, 10.0.17

Type: Bug Priority: Minor
Reporter: Alexander Pankov Assignee: Sergei Golubchik
Resolution: Fixed Votes: 0
Labels: libmysqlclient
Environment:

CentOS, Fedora, RHEL


Attachments: File cli_safe_read_export.diff    

 Description   

Function cli_safe_read is very important for custom client software, which do read DB answer. Without this function you can not implement custom slave library:

https://github.com/dimarik/mysqlslave

Moreover, some other projects need it, for example Facebook's HipHop:
http://nareshv.blogspot.in/2011/10/building-facebooks-hiphop-on-fedora-15.html

It's easy to add cli_safe_read function to export list in libmysql/CMakeLists.txt



 Comments   
Comment by Alexander Pankov [ 2015-01-09 ]

For Windows users we should add STDCALL macros to

include/sql_common.h:
unsigned long STDCALL cli_safe_read(MYSQL *mysql);

sql-common/client.c:
ulong STDCALL
cli_safe_read(MYSQL *mysql)

Comment by Alexander Pankov [ 2015-01-09 ]

I edited ticket, this issue affects all versions of MariaDB.

Also I attach a small diff, which could be applied on all versions.

Comment by Alexander Pankov [ 2015-01-09 ]

patch to fix issue 7419

Comment by Alexander Pankov [ 2015-02-09 ]

Anybody read this issue?

I can send patch, it's small and won't break anything...

Comment by Sergei Golubchik [ 2015-02-09 ]

Nobody read it yet, because there were no 5.5 releases between the date this issue was created and today. But somebody (probably, I) will certainly read it before the next 5.5 release.

Comment by Alexander Pankov [ 2015-02-10 ]

I set 5.5 release, but this issue is for all versions.

cli_safe_read() is the only way to read raw MySQL answer at client side, and that's why should be exported.

Comment by Sergei Golubchik [ 2015-02-12 ]

I see. But MariaDB client API was never supposed to provide access to the raw network packets. It only had high-level functions.

I kind of agree that it could be useful to provide a lower-level API, that allows to manipulate raw packets. But I don't really want to do it in an ad-hoc manner by exporting internal functions on request.

So, what low-level functionality one may need? Reading a packet, like cli_safe_read(), sure. Writing a packet? What one needs to parse a data packet? net_field_length() like in that Facebook's HipHop link? Anything else?

Comment by Alexander Pankov [ 2015-02-13 ]

You are right, it is not good idea to export internal functions, but there is no other way to do some things.

I can speak only about my piece of software — C++ library for getting replication log, and it requires two functions: cli_safe_read() and net_field_length().
It is easy to copy/paste net_field_length(), and I did it already, but no way to make any replacement for cli_safe_read().

But it is good idea to add both functions — for reading and writing packets to socket.

I know, this looks to be dirty hack, but almost all export functions in that list are hacks.

Comment by Sergei Golubchik [ 2015-02-13 ]

okay. I'll export cli_safe_read() and net_field_length(), but rename them to have mysql_ prefix.
mysql_net_read_packet() and mysql_net_field_length().

Comment by Alexander Pankov [ 2015-02-13 ]

Thanks!

It is good idea to use prefixes, but how can I detect which function I have?

Are there any defines to check whether I have to user function with prefix or not?

Comment by Sergei Golubchik [ 2015-02-13 ]

You can do, say

#if MYSQL_VERSION_ID > 50541 && defined(MARIADB_BASE_VERSION)
/* MariaDB-5.5.42 or later, with low-level mysql_net_ API */
#else
#define mysql_net_read_packet cli_safe_read
#define mysql_net_field_length net_field_length
#endif

Comment by Alexander Pankov [ 2015-02-14 ]

One more question, have you merged thinge to 10.0.x and 10.1.x branches?

Comment by Sergei Golubchik [ 2015-02-14 ]

No, I have not. But, of course, I will. This change will be in the next 10.0 release. And in the next 10.1 that follows in the next 10.0 release. That is, in 10.0.17 and 10.1.4

Generated at Thu Feb 08 07:19:27 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.