List-type secondary index in 3.5.8

Aerospike 3.5.8 should have support for indexing list bins.

Here is the code that compiles & executes without errors, but does not produce expected results, i.e. query does not find expected records:

UPDATE: the code that I posted here had error in it. I’m happy to report that indexing & querying on Bins of type List works as expected. Bravo Aerospike!

1 Like

Hi,

Aerospike does not index the contents of a list in this release. The Java Client (3.1.1+) has new APIs for this kind of indexing and queries, but the Aerospike server code is currently undergoing performance testing and is not released yet.

BTW: If the secondary index is created, each write (put) will be immediately consistent with the secondary index, so you dont need to sleep.

I hope this helps

Peter

Hi Peter,

it actually works for me in 3.5.8 server and 3.1.1 java client. I can post the working code if you like.

1 Like

Peter K

Please do post the code as example for all the forum users.

Peter

Here is the example code that queries list-type bin for string “content”. Out of 100 records containing list-type bins with random words, 10 contain word “content” :

	@Test
public void testListQueryNative() {

	Random random = new Random();

	AerospikeClient client = new AerospikeClient("localhost", 3000);
	String namespace = "test";
	String setName = "testSetQuery";
	String stringListIndex = "index_list_string";
	String binString = "binString";

	client.createIndex(new Policy(), namespace, setName, stringListIndex, binString, IndexType.STRING, IndexCollectionType.LIST);

	// create records
	for (int i = 0; i < 100; i++) {
		Key key = new Key(namespace, setName, random.nextLong());
		Bin listStringBin;

		List<String> listStrings = new ArrayList<>();

		// subset of records have predictable bin values - so they can be found by query
		if (i % 10 == 0) {
			listStrings.add("content"); // fixed string
		}

		// random strings added to list
		listStrings.add(TestUtils.randomWord());
		listStrings.add(TestUtils.randomWord());
		listStringBin = new Bin(binString, listStrings);

		client.put(null, key, listStringBin);

	}

	Statement statement = new Statement();
	statement.setIndexName(stringListIndex);
	statement.setNamespace(namespace);
	statement.setSetName(setName);
	statement.setFilters(Filter.contains(binString, IndexCollectionType.LIST, "content"));

	RecordSet recSet = client.query(null, statement);

	int count = 0;
	while (recSet.next()) {
		count++;
		Record record = recSet.getRecord();
		Assert.assertTrue(((List) record.bins.get(binString)).contains("content"));
	}

	// query should return 10 records
	Assert.assertEquals(10, count);
}
1 Like

I tried to use list secondary index on 3.5.14 through python library and was able to create the index. But while quering I got

error: (201L, 'AEROSPIKE_ERR_INDEX_NOT_FOUND', 'src/main/aerospike/aerospike_query.c', 228)

I think they still do not have support for it. @Peterknego can you confirm that you are still able to use it?

I’m using a list type secondary index with Java client. I have no experience with Python client.

As mentioned in the Python documentation, the client-side has it implemented, but it’s not yet an implemented server-side featue.

@Peterknego: How is it possible (I mean it is but still)? Server code is the same so if python client supports it why does server doesn’t? The server code remains the same irrespective of the client type right?

@rbotzer I posted a working Java code above. How does it work if feature is not available on the server? Am I missing something?

Hi, I am curious: Is there an update to the status of this feature?

The test by @Peterknego works for me (Java Client 3.1.8 and Aerospike server 3.7.0.2).

The Java client doc mentions it and does not indicate any limitation on either the client or server side: http://www.aerospike.com/apidocs/java/com/aerospike/client/query/IndexCollectionType.html.

The server has had “support” for indexing list bins for long while, but the implementation often gave unreliable results. The java client added support for this feature, so it could be used when the server implementation improved. Future releases of the server should greatly improve reliability on queries which filter on list bins.

1 Like