Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

烦人的空白行 #15

Open
biergaizi opened this issue Aug 3, 2013 · 1 comment
Open

烦人的空白行 #15

biergaizi opened this issue Aug 3, 2013 · 1 comment

Comments

@biergaizi
Copy link

#1
[16:08] <wecasebot> qq(发起人) :我还活着!
[16:08] <wecasebot> 【提示:此用户正在使用Q+ Web:http://web2.qq.com/】

#2
[16:09] <wecasebot> qq(发起人) :?
[16:09] <wecasebot>  

在对方使用 Web QQ 发送第一条信息时,会出现 #1 的现象。之后,会出现 #2 的现象。空白行严重影响阅读。

@microcai
Copy link
Member

microcai commented Aug 4, 2013

Soga !

Jackarain added a commit that referenced this issue Apr 12, 2014
Fix for using he same keep-alive connection to perform several requests ...
microcai pushed a commit that referenced this issue Apr 12, 2014
Waiting for resolution of the issue #15 which may lead to changes in public interface behaviour. See the issue comments and the discussion thread on soci-users.
microcai pushed a commit that referenced this issue Apr 12, 2014
Clarify supported sequence of statement::execute(false|true) and
statement::get_affected_rows() calls across all backends:
1. execute(false) and empty destination does not execute statement, but
prepares for subsequent statement::fetch() requests.
2. execute(true)  and empty destination calls requests backend to
execute statement.
3. execute(false|true) causes bulk fetch to destination, with
withDataExchange=false|true ignored.
Moved relevant test to common tests, confirmed it passes for all but
Oracle (get_affected_rows not implemented) and Firebird (I have no means
to test).
Related discussion at
http://sourceforge.net/mailarchive/message.php?msg_id=30312517
Thanks to Sergei who first proposed this behaviour as reliable and
consistent option, yet not intrusive.
microcai pushed a commit that referenced this issue Apr 12, 2014
Clarify supported sequence of statement::execute(false|true) and
statement::get_affected_rows() calls across all backends:
1. execute(false) and empty destination does not execute statement, but
prepares for subsequent statement::fetch() requests.
2. execute(true)  and empty destination calls requests backend to
execute statement.
3. execute(false|true) causes bulk fetch to destination, with
withDataExchange=false|true ignored.
Moved relevant test to common tests, confirmed it passes for all but
Oracle (get_affected_rows not implemented) and Firebird (I have no means
to test).
Related discussion at
http://sourceforge.net/mailarchive/message.php?msg_id=30312517
Thanks to Sergei who first proposed this behaviour as reliable and
consistent option, yet not intrusive.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants