Okay, but since the nested object structure that I have contains a Map<String, Object>, for which the idea is to have dynamic values, I'm not sure how it will be handled. Do I need to create a separate table to do the mapping of said Map<>? Couldn't find an example mapping a query entity entry to a parameterized value.
On Wed, 26 May 2021 at 17:01, Stephen Darlington < stephen.darling...@gridgain.com> wrote: > A scan isn’t ordered. As you suspect, the way to order queries in Ignite > is to use SQL. > > You don’t need to use annotations to define your SQL fields, indexes, etc. > A slightly more verbose way is to use Query Entities (indexes > <https://ignite.apache.org/docs/latest/SQL/indexes#configuring-indexes-using-query-entities> > ). > > On 26 May 2021, at 14:24, Taner Ilyazov <taner.ilya...@gmail.com> wrote: > > Hello everyone, > > I'm new to the community and fairly new to Apache Ignite. I have a > question for which I couldn't find a confirmation if it's possible or not. > > I have a use case where I need to persist a certain POJO to an ignite > cluster. The POJO can not be changed, so adding @SqlQueryField to it's > fields is not possible. Creating a data transfer object is an option, but I > think adding mapping from/to the actual POJO will result in too much > overhead, since performance requirements are really high. > > For now I'm using ScanQuery, but I could not find a way to sort the result > based on a field value. So my main question is if it's possible and if not, > what other options are there because the amount of data in question is too > much for sorting on client side. > > If I take the SQL approach and introduce the mapping overhead between the > DTO and POJO can I achieve server-side sorting on multiple nodes, keeping > in mind that we'll have 1 table with a huge amount of data for writing and > reading. > Co-location if I understand correctly is ensuring all related data is on > the same nodes, but in our case we have a single POJO which I would like > it's data to be separated on different nodes for performance. > > > > > >
