Welcome to the new Gigaspaces XAP forum. To recover your account, please follow these instructions.

Ask Your Question
0

Is it possible to return just the payload of POJO in response to space read

I've got another question on the forum, which is to do with reading object. Here I'm asking a similar thing, though in a different way. I've made it a new question to avoid confusing myself further.

Given a POJO in a space which has several index field and a payload (in my case a string) you can do a query to get the an object back from the space easily enough:

So given:

@SpaceClass public class Person { private Integer id; private String name; private String lastName; private Integer age;
...... }

you can do :

MyClass result1 = gigaSpace.read( new SQLQuery<person>(Person.class, "age > 50"));

which will return all the the people who are over 50.

It is possible to directly retrieve a single field of the POJO. So for example just retrieve all the lastNames of the people over 50.

I'd like to do this as in some cases the clients are only really interested in the Payload of the space class. The index fields are duplicated data which where is no need to return and they also tie the client to version of the POJO used to store the payload in the space. So adding a new index field will break clients which are not upgraded. In my case the client's don't care about the index field, only the payload so I'd like to avoid coupling the clients to the POJO's index fields if possible.

I realise this may be a good use of the document format which has been added in GS. However, I'd prefer to avoid that (as we have to have C++ connectivity) and my current project has it own document format which I'd like to embed in the payload.

Again, it does not look like this is possible, as I cannot find an example how how it would be done. If anyone can point me in the right direction it would be very much appreciated.

S

{quote}This thread was imported from the previous forum. For your reference, the original is [available here|http://forum.openspaces.org/thread.jspa?threadID=3860]{quote}

asked 2012-05-21 12:55:14 -0500

updated 2013-08-08 09:52:00 -0500

jaissefsfex gravatar image
edit retag flag offensive close merge delete

2 Answers

Sort by ยป oldest newest most voted
0

Sam,

First of all you will need to use readMultiple() call and not read() to get all the People objects that match this SQL.

You have the following options implementing partial read:
- Use the JDBC API and have as part of the select section the relevant fields listed. You can write the data using POJOs and read using JDBC.See:
http://www.gigaspaces.com/wiki/display/XAP9/JDBCDriver
http://www.gigaspaces.com/wiki/display/XAP9/JDBCDriver#JDBCDriver-GettingJDBCconnectionfromaSpaceProxy

- Use Task Executor that will read the data and return only the fields you are interested with. See:
http://www.gigaspaces.com/wiki/display/XAP9/TaskExecutionovertheSpace

Shay

answered 2012-05-21 13:42:11 -0500

shay hassidim gravatar image
edit flag offensive delete link more
0

Hi,

Thanks once again for replying.

I'd been looking at those two options. The Task Executor seems by far the better approach. The only problem with that is the Interopability. I didn't mention this interop question in the original question. But the main reason for wanting to only load the payloads of objects is to avoid having to maintain versions of the DTOs in different languages.

I'd tried to set-up a Java task which can be successfully be called from a Java client via an ExecutorRemotingProxyConfigurer. Trying to invoke the same task from a .Net client via an ExecutorRemotingProxyBuilder results in an "No AppDomain is associated with the context class loader" exception.

After a lot of investigation I've come to the conclusion that there is no Interopability for tasks in GS 9.0 which is a bit of a problem for us (though I admit that I could well be wrong). Is that the case? For us the tasks are quite complex and we have Java, C, C++ clients and cannot maintain three versions of the task code.

James

answered 2012-05-23 10:36:19 -0500

edit flag offensive delete link more

Comments

You are right, there is no such interoperability yet.
What you could do is use a polling container and command pattern so the the command invoke and result are interoperable space classes and the command execution code is written only in Java (or .NET) and the polling container execute it upon command request.

Eitan.

eitany gravatar imageeitany ( 2012-05-23 10:56:04 -0500 )edit

James, You can deploy a simple web service that will be called by the C++/.Net . You can deploy it into the same GSCs used for the data-grid or have a dedicated one. It will be a mediator between the C++/.Net clients and the Data-Grid. It will have a small latency footprint (extra network hop compared to the Java client), but will allow you to use the same Java Task /JDBC call from every client. See example: http://www.gigaspaces.com/wiki/displa...

Shay

shay hassidim gravatar imageshay hassidim ( 2012-05-23 11:04:20 -0500 )edit

Thank you both, for replying.

Yes, we had consider the web services option and there are some arguments for taking that approach anyway. To my mind the one of the reasons GS appeals was I thought you don't need the web service layer which can simplify the application stack. The web server requires set-up and monitoring and can go wrong so if you can get rid of it all the better.

I'd though about the polling container and command pattern approach, but I could see some flaws. The theory was to use the space like a queue. The client writes command objects to the space and polling container picks them up and does what ever processing is required. Then the results are then written to the space in a result object which the client can read. Meanwhile the client simply polls the space until it sees some kind of completion flag which is written by the server side polling container. Aside from being a bit messy, the problems I could not overcome with this approach are;

1. If, as in my case, the results of the task are object payloads which are already in the space the these have to be duplicated in the space in a result object so they can be read by the client.
2. If the number of objects to be read or the payloads themselves are very large then this is a considerable overhead.
4. Any kind of client side local cache would no longer work because each time a result is written a new ID is generated for it.

I assume there will be no chance of any task interoperability until at least GS 10 or beyond, and you don't wan to reveal the roadmap on forum. So we have to decide how we can work around it for the minute. Other comments are welcome, and as ever much appreciated.

S

greek87 gravatar imagegreek87 ( 2012-05-23 11:53:45 -0500 )edit

James,

Future versions will support Task interoperability. It is on our plans. The web services option is simple since you don't need any additonal web container or any other special managment. GigaSpaces will host it nativly within the GSC and manage it. So you can use it until we will have Task interoperability fully supported.

As far as the command pattern approach, you don't need to duplicate any data. Just have the ID(IDs) sent back to the client and it will read these via their IDs (readbyId/readByIds). You could also place the actual data within the result object and it will be removed once the result object will be consumted (polling container at the client side). So the overhead for these will be minimal.

If you are looking for more details about our roadmap please contact me: shay at gigaspaces.com

Regards, Shay

shay hassidim gravatar imageshay hassidim ( 2012-05-25 10:55:09 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2012-05-21 12:55:14 -0500

Seen: 85 times

Last updated: May 23 '12