It is pretty easy to make Query and SqlQuery Serializable and add that bit of API.

However, there is a semi-related issue of multi-tier (aka 3 tier) type applications - at least in my mind.

Specifically I have been thinking about the issues around having a Java Client (Ebean Client) that talks (say via https) to a server (Ebean Server) along the lines of 3 tier client server.

The issues being that in a 3 tier approach are things like more performant fetching (via array fetching) and batching of multiple "commands" into a single network roundtrip.

This may be over-engineering for what you are looking for... I previously had some code that did bits of this etc and I am thinking of having another go at building this 3 tier mechanism again.

Anyone got any thoughts, ideas etc on this?

Thanks, Rob.

Another way of saying this...

... making Query Serializable etc is straight forward

... but a more serious solution to 3 tier development would include array fetching and an API that allowed you to batch multiple "commands" into a single network roundtrip.

"Array Fetching" meaning that the client gets the first X beans in the list and the rest are retrieved on demand from the server.

"Batching multiple commands" meaning you can batch multiple commands such as find, save, delete, begin transaction and commit transaction into a single network roundtrip.

I have made Query Serializable ...

example...

FileInputStream fi = new FileInputStream("to.ser");
ObjectInputStream ois = new ObjectInputStream(fi);


Query<Order> q = (Query<Order>)ois.readObject();

List<Order> list = Ebean.getServer(null).findList(q, null);
System.out.println(list);

Note that Ebean.getServer(null) returns the default EbeanServer. That has methods on it to

list = EbeanServer.findList(query, transaction);
set = EbeanServer.findSet(query, transaction);
map = EbeanServer.findMap(query, transaction);

NB: transaction can be null.

I'll leave it like this for the moment rather than add those methods onto Ebean, and see how that goes for people.

Cheers, Rob.