str instead of string

[pgulutzan]

I have Ubuntu 18.04. I have Tarantool 2.3, pulled from source today.

I execute this request:

tarantool> box.space._space:select(364)

• • [364, 1, '_ck_constraint', 'memtx', 0, {}, [{'name': 'space_id', 'type': 'unsigned'},
    {'name': 'name', 'type': 'string'}, {'name': 'is_deferred', 'type': 'boolean'},
    {'name': 'language', 'type': 'str'}, {'name': 'code', 'type': 'str'}]]
    ...

I do not believe that language should be 'str' and code should be 'str'.
All other string fields in system spaces are 'string'.

In fact I believe that always when I use a synonym (during creation
of a format or an index) the result should be the canonical form not
the synonym. (I do not test whether this is always true.)
I notice that when in SQL I say
CREATE TABLE things (remark TEXT PRIMARY KEY);
the result is a 'string' not a 'text'.

[ImeevMA]

Currently, the only way to get this field_type in _space is to create a space in Lua.

Also:

1. There are three field_type aliases in create_space(): 'num' for UNSIGNED, 'str' for STRING, and '*' for ANY.
   In this case, an alias will be shown in _space if it was used when creating the space.
2. There are four field_type aliases in create_index(): 'uint' for UNSIGNED is added to the list above.
   In this case, a canonical name will be shown in _index.

[ImeevMA]

Still, you can get aliases in _space and _index using something like this:

tarantool> function setmap(table) return setmetatable(table, { __serialize = 'map' }) end
---
...

tarantool> box.space._space:insert({512, 1, 'a', 'memtx', 1, setmap({}), {{name = 'u', type = 'num'}}})
---
- [512, 1, 'a', 'memtx', 1, {}, [{'name': 'u', 'type': 'num'}]]
...

tarantool> box.space._index:insert({512, 0, 'aa', 'tree', setmap({}), {{1, 'num'}}})
---
- [512, 0, 'aa', 'tree', {}, [[1, 'num']]]
...

Also, 'uint' is not supported for _index in this case.

I think this is a legacy, but not sure if this is a bug.
@pgulutzan Do you still think that this is a bug?

PS. I think it might be a good idea to change the field type to canonical if the space was created using “box.schema.space:create()” or “box.schema.create_space()”. In this case, it will not be a bug, but a feature, I think.

[pgulutzan]

Okay, call it a feature request instead of a bug. But if everybody realizes that the stored type name should always be the same, what difference does it make?