Skip to content
Snippets Groups Projects
  • Vladislav Shpilevoy's avatar
    39918baf
    key_def: key_def.new() accept both 'field' and 'fieldno' · 39918baf
    Vladislav Shpilevoy authored
    Closes #4519
    
    @TarantoolBot document
    Title: key_def.new() accept both 'field' and 'fieldno'
    
    Before the patch key_def.new() took an index part
    array as it is returned in <index_object>.parts: each
    part should include 'type', 'fieldno', and what else
    .parts element contains.
    
    But it was not possible to create a key_def from an
    index definition - the array passed to
    <space_object>.create_index() 'parts' argument. Because
    key_def.new() didn't recognize 'field' option. That
    might be useful, when a key_def is needed on a remote
    client, where a space object and its indexes do not
    exist. And it would be strange to force a user to
    create them just so as he would be able to access
    
        <net_box connection>.space.<space_name>.
            index.<index_name>.parts
    
    As well as it would be crutchy to make a user manually
    replace 'field' with 'fieldno' in its index definition
    just to create a key_def.
    
    Additionally, an ability to pass an index definition
    to a key_def constructor makes the API more symmetric.
    
    Note, that it still is not 100% symmetric, because a
    user can't pass field names to the key_def
    constructor. A space is needed for that anyway.
    39918baf
    History
    key_def: key_def.new() accept both 'field' and 'fieldno'
    Vladislav Shpilevoy authored
    Closes #4519
    
    @TarantoolBot document
    Title: key_def.new() accept both 'field' and 'fieldno'
    
    Before the patch key_def.new() took an index part
    array as it is returned in <index_object>.parts: each
    part should include 'type', 'fieldno', and what else
    .parts element contains.
    
    But it was not possible to create a key_def from an
    index definition - the array passed to
    <space_object>.create_index() 'parts' argument. Because
    key_def.new() didn't recognize 'field' option. That
    might be useful, when a key_def is needed on a remote
    client, where a space object and its indexes do not
    exist. And it would be strange to force a user to
    create them just so as he would be able to access
    
        <net_box connection>.space.<space_name>.
            index.<index_name>.parts
    
    As well as it would be crutchy to make a user manually
    replace 'field' with 'fieldno' in its index definition
    just to create a key_def.
    
    Additionally, an ability to pass an index definition
    to a key_def constructor makes the API more symmetric.
    
    Note, that it still is not 100% symmetric, because a
    user can't pass field names to the key_def
    constructor. A space is needed for that anyway.