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.

Sign up for GitHub

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

Jump to bottom

Case-sensitive commands in console #5993

Closed
Severogor opened this issue Apr 15, 2016 · 7 comments
Closed

Case-sensitive commands in console #5993

Severogor opened this issue Apr 15, 2016 · 7 comments
Assignees
@luigidellaquila
Labels
bug
Milestone
2.1.17

Comments

@Severogor
Copy link

Severogor commented Apr 15, 2016 •
edited

OrientDB Enterprise 2.1.13.

SELECT out.uid, in.uid from FOLLOWS where out.uid = 1 LIMIT 1

----+------+----------+---------
#   |@CLASS|out       |in
----+------+----------+---------
0   |null  |                 1|                 2
----+------+----------+---------

SELECT out.uid, in.uid from FOLLOWS where out.uid = 1 Limit 100

----+------+----------+----------
#   |@CLASS|out       |in
----+------+----------+----------
0   |null  |                 1|                 2
...
19  |null  |                 1|                 21
----+------+----------+----------
LIMIT EXCEEDED: resultset contains more items not displayed (limit=20)

The same record limit also gives LIMIT -1 etc. As far as I understand, the LIMIT N (writing other than lowercase) gives correct results only in cases when N is in the interval (0, 20).
Seems like the LIMIT statement is case-sensitive in console and binary protocol (with pyorient) because it works correctly only in lowercase.

So and quit/exit...

orientdb {db=data}> EXIT

!Unrecognized command: 'EXIT'
orientdb {db=data}> QUIT

!Unrecognized command: 'QUIT'
orientdb {db=data}> exit

May be I misunderstand something and some commands are made case-sensitive?.

Another thing with limit:

orientdb {db=logistics}> select from container LIMIT 0

Error: com.orientechnologies.orient.core.sql.OCommandSQLParsingException: Error on parsing command at position #27: Invalid LIMIT value setted to ZERO. Use -1 to ignore the limit or use a positive number. Example: LIMIT 10
Command: SELECT FROM container LIMIT 0
-----------------------------------^

What's the problem with selecting 0 records?..
PostgreSQL 9.4.5

data=# select from container limit 0;
--
(0 rows)

Why do I set as an example PostgreSQL? Because in my (and not only my) practice it is very stable, mature and its developer interface is VERY, VERY convenient. I wish that to OrientDB!
Thanks.
@smolinari
Copy link
Contributor

The better suggestion is to explain why a LIMIT 0 might be useful. For instance, it could be a fast method to check the validity of a query.

As for the LIMIT, Limit or limit problem, that needs to be checked.

Scott

@luigidellaquila
Copy link
Member

Hi @Severogor

It seems be a matter of wrong pre-parsing in the console application, I'll check it soon

Thanks

Luigi

@luigidellaquila luigidellaquila self-assigned this Apr 18, 2016
@luigidellaquila luigidellaquila added this to the 2.1.x (next hotfix) milestone Apr 18, 2016
@Severogor
Copy link
Author

Hi,
Please check column names also.

orientdb {db=userdata}> SELECT FROM TEST WHERE a is null

0 item(s) found. Query executed in 0.001 sec(s).
orientdb {db=userdata}> SELECT FROM TEST WHERE A is null

----+-----+---------+----+----
#   |@RID |@CLASS   |a   |b   
----+-----+---------+----+----
0   |#58:0|TEST   |1   |x   
----+-----+---------+----+----

1 item(s) found. Query executed in 0.001 sec(s).

Thanks.
S.

@Severogor
Copy link
Author

orientdb {db=userdata}> CREATE EDGE LINK FROM #14:0 TO #29:3 SET ACTION =
"Relate";

Error: com.orientechnologies.orient.core.exception.OValidationException:
The field 'ACTION.action' is mandatory, but not found on record:
LINK#41:-2{ACTION:Relate,out:#14:0,in:#29:3,instructions:[0],process:} v0

orientdb {db=userdata}> CREATE EDGE LINK FROM #14:0 TO #29:3 SET action =
"Relate";

Created edge
'[LINK#41:2{action:Relate,out:#14:0,in:#29:3,instructions:[0],process:,status:0}
v1]' in 0,002000 sec(s).

On Mon, Apr 18, 2016 at 1:56 PM, luigidellaquila notifications@github.com
wrote:

Hi @Severogor https://github.com/Severogor

It seems be a matter of wrong pre-parsing in the console application, I'll
check it soon

Thanks

Luigi

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#5993 (comment)

luigidellaquila added a commit that referenced this issue May 4, 2016
@luigidellaquila
Fix case sensitivity problems in console (limit, exit, quit)
7cd8f5d 
Resolves: #5993
@luigidellaquila
Copy link
Member

Hi guys,

I just pushed a fix to 2.1.x branch, the fix will be in next 2.1.17

This fix resolves the problems with LIMIT, EXIT, QUIT.

LIMIT 0 was never supported, maybe it will be in the future, but I cannot guarantee it.

Property names are case sensitive in OrientDB, @Severogor this should explain your case

Thanks

Luigi

luigidellaquila added a commit that referenced this issue May 4, 2016
@luigidellaquila
Fix case sensitivity problems in console (limit, exit, quit)
09bb268 
Resolves: #5993
@Severogor
Copy link
Author

Hello,

Thank you for your fix very much!

Property names are case sensitive in OrientDB, @Severogor
https://github.com/Severogor this should explain your case

If so, why does the ALTER block alter properties case-insensitive?

For example,
orientdb {db=data}> alter property FOLLOWS.REVISION NOTNULL True
Property updated successfully

orientdb {db=data}> alter property FOLLOWS.Revision NOTNULL False
Property updated successfully

orientdb {db=data}> ALTER PROPERTY FOLLOWS.revision NOTNULL True
Property updated successfully

All these commands change the FOLLOWS.revision NOTNULL property
respectively.

Best regards and thanks.

On Wed, May 4, 2016 at 3:15 PM, luigidellaquila notifications@github.com
wrote:

Closed #5993 #5993.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#5993 (comment)

@luigidellaquila
Copy link
Member

That's definitely a bug for me, I'll check it

Thanks

Luigi

@robfrank robfrank modified the milestones: 2.1.x (next hotfix), 2.1.17 May 15, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@luigidellaquila luigidellaquila

Labels
bug
Milestone
2.1.17
Development

No branches or pull requests
4 participants
@robfrank @luigidellaquila @smolinari @Severogor