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

Set iterator type for each index parts #3243

Open
NERON opened this issue Mar 16, 2018 · 3 comments
Open

Set iterator type for each index parts #3243

NERON opened this issue Mar 16, 2018 · 3 comments
Assignees
Labels
feature A new functionality

Comments

@NERON
Copy link

NERON commented Mar 16, 2018

Having index:
box.space.feeds:create_index('primary', { type = 'TREE',unique = true, parts = {1, 'unsigned',2,'unsigned',3,'unsigned'}})
I'm using pairs for iterating over index, but how can i set different iterator type for each parts: (EQ parts[1], LE parts[2],GE[3])?
In SQL we can set "order by" order for each field, but how we can do it by tarantool without writing special lua functions?

@kostja
Copy link
Contributor

kostja commented Mar 18, 2018

This is actually a very good idea, and we need it in SQL as well.

@kostja kostja added the feature A new functionality label Mar 18, 2018
@kostja kostja added this to the 1.10.1 milestone Mar 18, 2018
@kyukhin kyukhin assigned Korablev77 and unassigned Gerold103 May 21, 2018
@kostja kostja modified the milestones: 1.10.2, 2.1.0 May 30, 2018
@Khatskevich
Copy link
Contributor

Should this iterator walk only over a continuous range of tuples? Or skip unsuitable tuples?

E.g imagine data:

1. [1, 2]
2. [1, 3]
3. [2, 1]
4. [2, 2]
5. [2, 3]

What should the iterators return?:

  1. [GE=1, EQ=2] ([[1,2]] or [[1,2][2,2]]?)
  2. [GE=1, LE=1] ([[2,1]] or [[]]?)
  3. [GE=1, LE=2] ([[1,2]] or [[1,2],[2,2]]?)
  4. Some other (more complex) cases.

@locker
Copy link
Member

locker commented Oct 1, 2018

Should this iterator walk only over a continuous range of tuples? Or skip unsuitable tuples?

E.g imagine data:

1. [1, 2]
2. [1, 3]
3. [2, 1]
4. [2, 2]
5. [2, 3]

What should the iterators return?:

  1. [GE=1, EQ=2] ([[1,2]] or [[1,2][2,2]]?)

[[1,2][2,2]]

  1. [GE=1, LE=1] ([[2,1]] or [[]]?)

[[2,1]]

  1. [GE=1, LE=2] ([[1,2]] or [[1,2],[2,2]]?)

[[1,2],[2,1],[2,2]]

In other words, a multi-directional iterator should return all tuples matching the given criteria, even if they don't constitute a singe range. That would match the behavior of SQL SELECT statement.

@locker locker removed the in progress label Oct 6, 2018
@kyukhin kyukhin modified the milestones: 2.1.0, 2.1.1 Oct 25, 2018
@kostja kostja modified the milestones: 2.1.1, wishlist Nov 19, 2018
Korablev77 added a commit that referenced this issue Jan 24, 2020
Korablev77 added a commit that referenced this issue Jan 26, 2020
Korablev77 added a commit that referenced this issue Jan 26, 2020
Korablev77 added a commit that referenced this issue Jan 26, 2020
Korablev77 added a commit that referenced this issue Nov 17, 2020
@alyapunov alyapunov added the 8sp label Sep 21, 2022
@kyukhin kyukhin removed this from the wishlist milestone Sep 21, 2022
@kyukhin kyukhin added the teamC label Sep 21, 2022
@kyukhin kyukhin removed 8sp labels Dec 22, 2022
ImeevMA added a commit to ImeevMA/tarantool that referenced this issue Feb 8, 2023
Prior to this patch, the SQL parser supported the sort order in the
index definition during index creation. However, all of our indexes are
ascending until tarantool#3243 is implemented, so the specified sort order was
simply ignored. To avoid a drastic change in behavior due to the
implementation of multidirectional indexes, we have decided to drop the
sort order from the index definition until tarantool#3243 is implemented.

Part of tarantool#8100

@TarantoolBot document
Title: ASC/DESC during index creation

Now the SQL parser does not support ASC/DESC when creating an index.
This used to be supported by the parser, but never worked.

An example of statements that are no longer supported:
```
CREATE TABLE t(i INT PRIMARY KEY ASC);
CREATE TABLE t(i INT PRIMARY KEY, a STRING, UNIQUE(a DESC));
CREATE INDEX i1 ON t(a ASC);
```
ImeevMA added a commit to ImeevMA/tarantool that referenced this issue Feb 8, 2023
Prior to this patch, the SQL parser supported the sort order in the
index definition during index creation. However, all of our indexes are
ascending until tarantool#3243 is implemented, so the specified sort order was
simply ignored. To avoid a drastic change in behavior due to the
implementation of multidirectional indexes, we have decided to drop the
sort order from the index definition until tarantool#3243 is implemented.

Part of tarantool#8100

@TarantoolBot document
Title: ASC/DESC during index creation

Now the SQL parser does not support ASC/DESC when creating an index.
This used to be supported by the parser, but never worked.

An example of statements that are no longer supported:
```
CREATE TABLE t(i INT PRIMARY KEY ASC);
CREATE TABLE t(i INT PRIMARY KEY, a STRING, UNIQUE(a DESC));
CREATE INDEX i1 ON t(a ASC);
```
ImeevMA added a commit to ImeevMA/tarantool that referenced this issue Feb 9, 2023
Prior to this patch, the SQL parser supported the sort order in the
index definition during index creation. However, all of our indexes are
ascending until tarantool#3243 is implemented, so the specified sort order was
simply ignored. To avoid a drastic change in behavior due to the
implementation of multidirectional indexes, we have decided to drop the
sort order from the index definition until tarantool#3243 is implemented.

Part of tarantool#8100

@TarantoolBot document
Title: ASC/DESC during index creation

Now the SQL parser does not support ASC/DESC when creating an index.
This used to be supported by the parser, but never worked.

An example of statements that are no longer supported:
```
CREATE TABLE t(i INT PRIMARY KEY ASC);
CREATE TABLE t(i INT PRIMARY KEY, a STRING, UNIQUE(a DESC));
CREATE INDEX i1 ON t(a ASC);
```
ImeevMA added a commit to ImeevMA/tarantool that referenced this issue Feb 21, 2023
Prior to this patch, the SQL parser supported the sort order in the
index definition during index creation. However, all of our indexes are
ascending until tarantool#3243 is implemented, so the specified sort order was
simply ignored. To avoid a drastic change in behavior due to the
implementation of multidirectional indexes, we have decided to drop the
sort order from the index definition until tarantool#3243 is implemented.

Part of tarantool#8100

@TarantoolBot document
Title: ASC/DESC during index creation

Now the SQL parser does not support ASC/DESC when creating an index.
This used to be supported by the parser, but never worked.

An example of statements that are no longer supported:
```
CREATE TABLE t(i INT PRIMARY KEY ASC);
CREATE TABLE t(i INT PRIMARY KEY, a STRING, UNIQUE(a DESC));
CREATE INDEX i1 ON t(a ASC);
```
ImeevMA added a commit to ImeevMA/tarantool that referenced this issue Feb 21, 2023
Prior to this patch, the SQL parser supported the sort order in the
index definition during index creation. However, all of our indexes are
ascending until tarantool#3243 is implemented, so the specified sort order was
simply ignored. To avoid a drastic change in behavior due to the
implementation of multidirectional indexes, we have decided to drop the
sort order from the index definition until tarantool#3243 is implemented.

Part of tarantool#8100

@TarantoolBot document
Title: ASC/DESC during index creation

Now the SQL parser does not support ASC/DESC when creating an index.
This used to be supported by the parser, but never worked.

An example of statements that are no longer supported:
```
CREATE TABLE t(i INT PRIMARY KEY ASC);
CREATE TABLE t(i INT PRIMARY KEY, a STRING, UNIQUE(a DESC));
CREATE INDEX i1 ON t(a ASC);
```
ImeevMA added a commit to ImeevMA/tarantool that referenced this issue Feb 21, 2023
Prior to this patch, the SQL parser supported the sort order in the
index definition during index creation. However, all of our indexes are
ascending until tarantool#3243 is implemented, so the specified sort order was
simply ignored. To avoid a drastic change in behavior due to the
implementation of multidirectional indexes, we have decided to drop the
sort order from the index definition until tarantool#3243 is implemented.

Part of tarantool#8100

@TarantoolBot document
Title: ASC/DESC during index creation

Now the SQL parser does not support ASC/DESC when creating an index.
This used to be supported by the parser, but never worked.

An example of statements that are no longer supported:
```
CREATE TABLE t(i INT PRIMARY KEY ASC);
CREATE TABLE t(i INT PRIMARY KEY, a STRING, UNIQUE(a DESC));
CREATE INDEX i1 ON t(a ASC);
```
@mkostoevr mkostoevr self-assigned this Jul 5, 2023
mkostoevr added a commit to mkostoevr/tarantool that referenced this issue Aug 2, 2023
mkostoevr added a commit to mkostoevr/tarantool that referenced this issue Aug 2, 2023
mkostoevr added a commit to mkostoevr/tarantool that referenced this issue Aug 2, 2023
mkostoevr added a commit to mkostoevr/tarantool that referenced this issue Aug 2, 2023
mkostoevr added a commit to mkostoevr/tarantool that referenced this issue Aug 2, 2023
mkostoevr added a commit to mkostoevr/tarantool that referenced this issue Aug 2, 2023
mkostoevr added a commit to mkostoevr/tarantool that referenced this issue Aug 3, 2023
mkostoevr added a commit to mkostoevr/tarantool that referenced this issue Aug 3, 2023
mkostoevr added a commit to mkostoevr/tarantool that referenced this issue Aug 3, 2023
mkostoevr added a commit to mkostoevr/tarantool that referenced this issue Aug 3, 2023
mkostoevr added a commit to mkostoevr/tarantool that referenced this issue Aug 3, 2023
mkostoevr added a commit to mkostoevr/tarantool that referenced this issue Aug 4, 2023
mkostoevr added a commit to mkostoevr/tarantool that referenced this issue Aug 4, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature A new functionality
Projects
None yet
Development

No branches or pull requests

9 participants