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

Update tool to use new API functionality [CORE4181] #4507

Open
firebird-automations opened this issue Aug 14, 2013 · 17 comments
Open

Update tool to use new API functionality [CORE4181] #4507

firebird-automations opened this issue Aug 14, 2013 · 17 comments

Comments

@firebird-automations
Copy link
Collaborator

Submitted by: @sim1984

Jira_subtask_outward CORE4317
Relate to CORE4317

The current version of isql uses the old API. As a result, we have a limit on the width of the sample in the 64K, and the length of the query. A simple example demonstrates this:

select lpad('', 30000, '1') as f1,
lpad('', 30000, '1') as f2,
lpad('', 15000, '1') as f3
from rdb$database

Statement failed, SQLSTATE = 07002
SQL error code = -804
-SQLDA missing or incorrect version, or incorrect number/type of variables
SQL>

In Firebird appeared packages, their body can be quite long. And it turns out that to run the script through isql to create the package will not work longer than 64K. Dmitry Yemanov also spoke about the fact that it is desirable that isql able to dynamically load a library fbclient in order to be able to work with the old version.

@firebird-automations
Copy link
Collaborator Author

Modified by: Sean Leyne (seanleyne)

summary: isql should be able to use the new API => Update tool to use new API functionality

@firebird-automations
Copy link
Collaborator Author

Commented by: @asfernandes

New API does not increase the maximum size of messages.

Amd FWIW, I'm running very large execute block, after increased the size of ISQL buffer.

Please test the current snapshot.

@firebird-automations
Copy link
Collaborator Author

Commented by: @sim1984

I checked isql on the large block.

1. Short block

set term ^;
execute block
returns (s integer)
as
begin
s = 5;
suspend;
end^
set term ;^

       S

============
5

2. Long block (~ 5 Mb)

set term ^;
execute block
returns (s integer)
as
begin
/***************************************************************************/
/***************************************************************************/
/***************************************************************************/
.................................................................
/***************************************************************************/
s = 5;
suspend;
end^
set term ;^

       S

============
5

It seems works. But there is a lot of comment and few commands. It is advisable to check certainly something more real.

@firebird-automations
Copy link
Collaborator Author

Commented by: Sean Leyne (seanleyne)

Adriano,

Unfortunately, the v3 Alpha release notes suggests otherwise.

Page 74 reads:

- The total size of all input or output parameters for a stored procedure or a user-defined DSQL query is no
longer limited to the traditional size of (64KB - overhead).

@firebird-automations
Copy link
Collaborator Author

Commented by: @asfernandes

This seems to be a documentation error.

@firebird-automations
Copy link
Collaborator Author

Commented by: @dyemanov

As the one who's responsible I respectfully disagree :-) First of all, there's no 64KB limit for the message length priorly defined by MAX_FORMAT_SIZE (see GEN_port for example). Now it's limited by MAX_MESSAGE_SIZE which is defined as 10MB. Secondly, new API offers 32-bit lengths for everything while the legacy one used 16-bit lengths for everything.

@firebird-automations
Copy link
Collaborator Author

Commented by: @sim1984

Adriano,

Then why CORE1609 fixed?

@firebird-automations
Copy link
Collaborator Author

Commented by: Sean Leyne (seanleyne)

@dmitry, so this is a real case/issue?

@firebird-automations
Copy link
Collaborator Author

Commented by: @dyemanov

Denis, I'm afraid CORE1609 is fixed only partially and may require reopening. There's no API level (message related) limit for procedures anymore, but there's still a 64KB record limit which applies to the current row of selectable procedures. In other words, you can execute a procedure returning >64KB in one row, but you cannot select from it. I'll look whether it's easily doable without increasing the table records length (which is a major ODS change).

@firebird-automations
Copy link
Collaborator Author

Commented by: @dyemanov

@sean, this ticket is valid. ISQL can execute longish queries just because it passes strings zero-terminated and does not pass their length (which is 16-bit in the old API). It gonna work with the new fbclient only, because older ones will truncate the string while passing it through the wire. But other extended limits (like the aforementioned input/output message size) require usage of the new API, ISQL cannot deal with such queries.

@firebird-automations
Copy link
Collaborator Author

Commented by: @asfernandes

Dmitry, I was not aware! But good then!

Then, if new limits can exists only in the old API, what prevent us from define metadata with real UTF-8 and have names with lengths greater than 31 *bytes* ?

The problem, as I known, was only to represent the names in the DSQL API.

@firebird-automations
Copy link
Collaborator Author

Commented by: Sean Leyne (seanleyne)

@dmitry, but if we are releasing a new build and ISQL uses FBClient, it would seem reasonable that the v3 ISQL tool should support all of the v3 functionality (to the full extent of the v3 Client API).

The fact that older clients (fbclient.dll) would not support the new functionality in understood.

@firebird-automations
Copy link
Collaborator Author

Commented by: @dyemanov

Adriano, in turn I may be ignorant about the metadata names vs DSQL API issue :-) If you mean limits inside XSQLVARs, then how longer metadata names could be accessed using the old API? Anyway, I suggest to move this discussion to fb-devel.

@firebird-automations
Copy link
Collaborator Author

Commented by: Sean Leyne (seanleyne)

@adriano, support for longer object names is a separate feature request, so let's not "pollute" this case with discussion on that subject.

That change, though, which would require a major ODS change (which it seems is being avoided in v3)

@firebird-automations
Copy link
Collaborator Author

Modified by: Sean Leyne (seanleyne)

Link: This issue relate to CORE4317 [ CORE4317 ]

@firebird-automations
Copy link
Collaborator Author

Commented by: @abzalov

@dmitry Yemanov

>>but there's still a 64KB record limit which applies to the current row of selectable procedures. In other words, you can execute a procedure returning >64KB in one row, but you cannot select from it.

Does this limit also applies to record size of result set from simple select query?
Does this limit exists in current release (3.0.1)?

According to the documentation (http://firebirdsql.org/file/documentation/release_notes/html/en/3_0/rnfb30-psql-limitsoff.html) this limits have been raised.
Or I have misunderstood?

@firebird-automations
Copy link
Collaborator Author

Commented by: @dyemanov

These limits are not actual in v3 anymore.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant