Issues when selecting an existing row in AQL


#1

I have a namespace and a set in aerospike with information inside. After performing a SELECT * FROM mytecache.search_results I get around 600 rows of this:

"bdee9a37e3217f28a057b5e0ebbef43f_Sabre_13" | "a:11:{s:5:"price";a:14:{s:5:"total";d:2947.5999999999999;s:11:"pricePerPax";d:1473.8;s:8:"totalflt";d:2947.5999999999999;s:9:"baseprice";d:1901.0799999999999;s:3:"tax";d:986.51999999999998;s:10:"servicefee";i:60;s:11:"markupprice";d:1961.0799999999999;s | "flight_bdee9a37e3217f28a057b5e0ebbef43f" | 147380 | LIST('["LH", "LH", "LH", "LH"]'....

As you know, the first column is the primary key, so I try to select the row (which just appeared in SELECT) with:

aql> SELECT * FROM mytecache.search_results WHERE PK = "bdee9a37e3217f28a057b5e0ebbef43f_Sabre_13"

and I get:

Error: (2) AEROSPIKE_ERR_RECORD_NOT_FOUND

Explain returns this: aql> EXPLAIN SELECT * FROM mytecache.search_results WHERE PK="bdee9a37e3217f28a057b5e0ebbef43f_Sabre_13" ±-----------------±-------------------------------------------±------------±----------±-------±--------±---------±---------------------------±------------------±------------------------±--------+ | SET | DIGEST | NAMESPACE | PARTITION | STATUS | UDF | KEY_TYPE | POLICY_REPLICA | NODE | POLICY_KEY | TIMEOUT | ±-----------------±-------------------------------------------±------------±----------±-------±--------±---------±---------------------------±------------------±------------------------±--------+ | “search_results” | “6F62BE5323F0A51EF7DFDD5060A02E62CD2453F0” | “mytecache” | 623 | 2 | “FALSE” | “STRING” | “AS_POLICY_REPLICA_MASTER” | “BB9B25B63000056” | “AS_POLICY_KEY_DEFAULT” | 1000 | ±-----------------±-------------------------------------------±------------±----------±-------±--------±---------±---------------------------±------------------±------------------------±--------+ 1 row in set (0.002 secs)

asinfo outputs: 1 : node BB9B25B63000056 2 : statistics cluster_size=1;cluster_key=883272F81547;cluster_integrity=true;cluster_is_member=true;uptime=1146;system_free_mem_pct=90;system_swapping=false;heap_allocated_kbytes=6525778;heap_active_kbytes= 6529792;heap_mapped_kbytes=6619136;heap_efficiency_pct=99;heap_site_count=14;objects=6191;tombstones=0;tsvc_queue=0;info_queue=0;delete_queue=0;rw_in_progress=0;proxy_in_progress=0;tree_gc_queue=0; client_connections=19;heartbeat_connections=0;fabric_connections=0;heartbeat_received_self=7637;heartbeat_received_foreign=0;reaped_fds=47;info_complete=12326;proxy_retry=0;demarshal_error=0;early_ tsvc_client_error=0;early_tsvc_batch_sub_error=0;early_tsvc_udf_sub_error=0;batch_index_initiate=0;batch_index_queue=0:0,0:0,0:0,0:0;batch_index_complete=0;batch_index_error=0;batch_index_timeout=0 ;batch_index_unused_buffers=0;batch_index_huge_buffers=0;batch_index_created_buffers=0;batch_index_destroyed_buffers=0;batch_initiate=0;batch_queue=0;batch_error=0;batch_timeout=0;scans_active=0;qu ery_short_running=0;query_long_running=0;sindex_ucgarbage_found=0;sindex_gc_locktimedout=0;sindex_gc_list_creation_time=39;sindex_gc_list_deletion_time=0;sindex_gc_objects_validated=11734;sindex_gc _garbage_found=0;sindex_gc_garbage_cleaned=0;paxos_principal=BB9B25B63000056;migrate_allowed=true;migrate_partitions_remaining=0;fabric_bulk_send_rate=0;fabric_bulk_recv_rate=0;fabric_ctrl_send_rat e=0;fabric_ctrl_recv_rate=0;fabric_meta_send_rate=0;fabric_meta_recv_rate=0;fabric_rw_send_rate=0;fabric_rw_recv_rate=0 3 : features peers;cdt-list;cdt-map;pipelining;geo;float;batch-index;replicas-all;replicas-master;replicas-prole;udf 4 : cluster-generation 1 5 : partition-generation 0 6 : build_time Sat Nov 4 02:19:49 UTC 2017 7 : edition Aerospike Community Edition 8 : version Aerospike Community Edition build 3.15.0.2 9 : build 3.15.0.2 10 : services

11 : services-alumni

12 : build_os debian8

Which seems wrong. Why is the query not returning the result, when it is clearly there ?

Crosspost from SO: https://stackoverflow.com/questions/48578196/aql-can-not-find-row-by-pk-row-is-there-when-selecting


#2

Answered on stackoverflow.


#3

This topic was automatically closed 6 days after the last reply. New replies are no longer allowed.