Cannot show the bin's content with aql command,is it a bug?

It cannot show bins by SELECT * FROM pub.Object where PK = ‘/pub/com/servlet/c1/1597865255’

but It can show bins with execute llist.scan(‘list’) on pub.Object where PK = ‘/pub/com/servlet/c1/1597865255’

like the follows:

I am not sure wether there is some inconsistency between my client API with aql tool or there some bugs in aql tool.

aql> SELECT * FROM pub.Object where PK = ‘/pub/com/servlet/c1/1597865255’

±--------------±-----±----------+

| LDTCONTROLBIN | list | LLIST_BIN |

±--------------±-----±----------+

| | | |

±--------------±-----±----------+

1 row in set (0.001 secs)

aql> execute llist.scan(‘list’) on pub.Object where PK = ‘/pub/com/servlet/c1/1597865255’

±------------------+

| scan |

±------------------+

| [“ctrl”, “media”] |

±------------------+

1 row in set (0.001 secs)

aql>

Steve,

Llist content are in server encoded format so aql cannot show bins in raw form, which anyways would be byte stream.

The way to look at their content is to use LLIST operations.

If you plan to use LDT, please see the http://www.aerospike.com/docs/guide/ldt_guide.html for current LDT recommendations and best practices.

– R

aql version 3.7.5 cannot show the bins content,but version 3.5.15 is okay like follows.we are using llist and ltd,so it seems queer.Anything changed?

aql> SELECT * FROM pub-.Object

----------------------±----------+

| key | LDTCONTROLBIN | list | LLIST_BIN | ±-----------------------------------------------±--------------±----------------------------------------

---------------------------------------------------------------------------------------------------------±– --------+ | “/sub/session/1/625975566” | | 91 A2 03 3E

Steve,

Ah !! Will check this and let you know.

– R

Hi,Raj

Thanks for your immediate reply.

My application use client version 4.04 and server 3.7.5.1 and tools is 3.7.5.but I try another aql command and it shows the right bin content like follows:

aql> execute llist.scan(‘list’) on pub-sub.Object where PK = ‘’/pub/com/servlet/c1/1597865255’’

±---------------------+

| scan |

±---------------------+

| [“1342286016/16258”] |

±---------------------+

1 row in set (0.000 secs)

I really have no clues what makes the difference of the command.

Best Regards,

Steve

Hello Steve –

Yes there is a difference between “SELECT” and “EXECUTE” regarding LDTs:

Since LDTs are special data structures, you need to access them via the Lua LDT APIs. This means using “EXECUTE”.

The “SELECT” command will not be able to display LDTs.

If you have more questions, please let us know.

Thanks.

Hi,Psi,

I find Large List command like “execute llist.scan(‘LLIST_BIN’) on test.demo where pk = 'Key_1”,which is used to query bins of single LDT record.But I donot find the Large List command which is used for querying one namespace.

Is there a command for querying the bins of the whole namspace?

Thanks,

Steve

Steve –

LDTs are data structures existing within a single bin on a record, accessed via record UDFs as in your example.

There are no AQL features for operating on LDTs across records, at the set or namespace level. This is an intentional design limitation, but not a bug.

1 Like

hello,Psi

I got it,but I still wonder we try “Select” on 3.6 and 3.5 version server and we got the right value of bins of LDT.but we try the query on 3.7.5.1,We got the bins of LDT are null.Is this coincidence or something changed?

With python client,the similiar situation is met.

python client code like follows:

def QueryData(self ,namespaces=namespaces ,set=set): res = self.client.query(namespaces ,set) return res.results()

On sever 3.6 version ,it can show the right value of Bins of LDT . however, 3.7.5.1 It shows bins of LDT as null.

It seems to me that both results should return null.

From the release note,I saw the two updates on scan option in server 3.7 and python client 2.0,Are these updates make query results different.

[AER-3789] - (Scan) Add option to include LDT data in scans. [CLIENT-609]Added the scan option include_ldt.

Best Regards,

Steve