Internal error on select by a space id and an index name #42
Comments
|
Ok, i've found where is error, but until i fix it, i suggest you to authenticate before start sending commands or using |
|
Sorry for long response. Everything must be OK by now. If it's not - please, reopen this bug and attach more information. Thank you! |
|
@bigbes Looks like it's still not possible to use index id. Now I get |
|
Also, in this test case https://github.com/tarantool/tarantool-php/blob/master/test/MockTest.php there is a defined |
|
This 'bug' requires major rewriting of schema. |
bigbes
added a commit
to bigbes/tarantool-php
that referenced
this issue
Jul 20, 2018
bigbes
added a commit
to bigbes/tarantool-php
that referenced
this issue
Jul 20, 2018
bigbes
added a commit
to bigbes/tarantool-php
that referenced
this issue
Dec 2, 2018
Totktonada
changed the title
MariaHajdic
pushed a commit
that referenced
this issue
Jun 16, 2020
MariaHajdic
added a commit
that referenced
this issue
Jun 16, 2020
…' into bigbes-gh-42-fetch-schema-anyway
|
NB: The problem appears only when a schema is not fetched at the moment of select() (or when it is obsoleted and does not contain relevant space). (I mean, the problem that is present after reopening the issue.) |
Totktonada
pushed a commit
to bigbes/tarantool-php
that referenced
this issue
Jul 13, 2020
When a space exists, but a client side schema does not know about it at the moment (say, right after connection), and when a user calls select() with a space id (number) and name of an index (string), the problem appears: the client raises the following error: | TarantoolParsingException: Failed to parse schema (index) However it should successfully perform the request. The problem is that when there is no record for a space in client's schema, it is not possible to save a record for an index of this space. The idea of the fix is to verify whether we know about a space even when a numeric ID is already provided. If a client has no record about the space, it fetches a schema and verify whether the space appears. If so, there is no more problem described above. Otherwise the client raises an error that the space with given ID does not exist. Closes tarantool#42 @Totktonada: polish code, polish test, write the description.
Totktonada
pushed a commit
to bigbes/tarantool-php
that referenced
this issue
Jul 17, 2020
When a space exists, but a client side schema does not know about it at the moment (say, right after connection), and when a user calls select() with a space id (number) and name of an index (string), the problem appears: the client raises the following error: | TarantoolParsingException: Failed to parse schema (index) However it should successfully perform the request. The problem is that when there is no record for a space in client's schema, it is not possible to save a record for an index of this space. The idea of the fix is to verify whether we know about a space even when a numeric ID is already provided. If a client has no record about the space, it fetches a schema and verify whether the space appears. If so, there is no more problem described above. Otherwise the client raises an error that the space with given ID does not exist. While we're here, ensure that return values of tarantool_schema_*() are checked against -1, not Zend's FAILURE macro (which is only guaranteed to be less than zero) in the modified code. Also ensure that the FAILURE macro is returned from the get_spaceno_by_name() function, not -1. Closes tarantool#42 @Totktonada: polish code, polish test, write the description.
Totktonada
pushed a commit
that referenced
this issue
Jul 17, 2020
When a space exists, but a client side schema does not know about it at the moment (say, right after connection), and when a user calls select() with a space id (number) and name of an index (string), the problem appears: the client raises the following error: | TarantoolParsingException: Failed to parse schema (index) However it should successfully perform the request. The problem is that when there is no record for a space in client's schema, it is not possible to save a record for an index of this space. The idea of the fix is to verify whether we know about a space even when a numeric ID is already provided. If a client has no record about the space, it fetches a schema and verify whether the space appears. If so, there is no more problem described above. Otherwise the client raises an error that the space with given ID does not exist. While we're here, ensure that return values of tarantool_schema_*() are checked against -1, not Zend's FAILURE macro (which is only guaranteed to be less than zero) in the modified code. Also ensure that the FAILURE macro is returned from the get_spaceno_by_name() function, not -1. Closes #42 @Totktonada: polish code, polish test, write the description.
Totktonada
added a commit
that referenced
this issue
Jul 17, 2020
Technically we should return FAILURE (not -1) from the changed function
in case of a failure. FAILURE is -1 in fact and it unlikely will be
changed, but the only formal guarantee we have is that FAILURE is a
negative value.
Cited from [1]:
| typedef enum {
| SUCCESS = 0,
| FAILURE = -1, /* this MUST stay a negative number, or it may affect functions! */
| } ZEND_RESULT_CODE;
No behaviour actually changed in this commit.
It is the follow up for 5647d24 ('Fix
select() by space_no and index_name'), where we initially set eyes on
this point.
[1]: https://github.com/php/php-src/blob/4903f7c5fde11a115f659ec54a1d0ede6fd7232c/Zend/zend_types.h#L53-L56
Follows up #42.
Totktonada
added a commit
that referenced
this issue
Jul 17, 2020
Technically we should return FAILURE (not -1) from the changed function
in case of a failure. FAILURE is -1 in fact and it unlikely will be
changed, but the only formal guarantee we have is that FAILURE is a
negative value.
Cited from [1]:
| typedef enum {
| SUCCESS = 0,
| FAILURE = -1, /* this MUST stay a negative number, or it may affect functions! */
| } ZEND_RESULT_CODE;
No behaviour actually changed in this commit.
It is the follow up for 5647d24 ('Fix
select() by space_no and index_name'), where we initially set eyes on
this point.
[1]: https://github.com/php/php-src/blob/4903f7c5fde11a115f659ec54a1d0ede6fd7232c/Zend/zend_types.h#L53-L56
Follows up #42.
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
fails with:
The text was updated successfully, but these errors were encountered: