chpruvos wrote:Yes, you can using a variant of KVStore.storeIterator(). The results are not necessarily sorted and they are not transactional. It is still good practice to be sure to use keys that sort well.
Thanks it was very interesting so just a few question...
- Do you confirm that we can do queries (a kind of..for exemple key range) just using key major components and not key minor components ?
- So For me no need to store attributes of a position not together. I can store key = Positions/$id and Value = Position (using Avro Serialization) ?It's not clear if this is a question or not. I'll just explain more things. The approach you seemed to be taking in your posts implied that you'd store a position as:
- If I want to be able to find all positions having symbol = "ORCL" then before when storing a position I need to update an index => key = /Symbols/$symbol/-/$id , Value = null. In this case I need to be carefull because if a put in Positions is OK but a put in the index is NOK then it could be a problem ?Correct. I personally would probably insert into indexes first, since that issue seems easier to handle but for a given application you may want the opposite behavior.
- To be more efficient if sorted key is needed then I should avoid to store an id like "10" but I should prefer an id like "000010" a fixed-length id ?Yes. In this case it'd make sense to create functions to easily map integers into fixed-length strings suitable for keys.
And to finish..That sort of thing is on the radar but I can't speak specifically about futures.
- What's about an index that will be manage automatically by Oracle NoSQL ? is it planned for a future release ?
Again Thank you for your answer ...No problem.