Another Request Factory Example (using MySQL)

[Andy King]

I have started to create another example/tutorial, this time using MySQL for the data (the first example just held the data in memory).  The example has some way to go before it is complete, but it may help others even in its current state.  The first part of the tutorial includes instructions for pulling the code from Google Code and for creating the database table.  Here's the link to the first part: GWT Request Factory & MySQL.  If you didn't go through the first tutorial, which is here: A GWT Request Factory Journey, then that may be a good idea to do first.

[Thomas Broyer]

On Thursday, November 22, 2012 6:17:22 AM UTC+1, Andy King wrote:

I have started to create another example/tutorial, this time using MySQL for the data (the first example just held the data in memory).  The example has some way to go before it is complete, but it may help others even in its current state.  The first part of the tutorial includes instructions for pulling the code from Google Code and for creating the database table.  Here's the link to the first part: GWT Request Factory & MySQL.  If you didn't go through the first tutorial, which is here: A GWT Request Factory Journey, then that may be a good idea to do first.

Your example would be much more helpful if it used JPA or JDO instead of your own GLBase project. Things you'll run into by rolling your own low-level solution include:

• you'll have to roll your own request-scoped entity cache: RF expects that a given entity is represented by the exact same instance for the duration of a request (e.g. you save a book from the client and retrieve the list of books in the same batch –RequestContext–, the book that has just been saved should be in the list retrieved afterwards, the same instance, not a new instance representing the same entity)
• to benefit from "saving only the bits that have changed", you'd like to track those changes within the entity
• implementing Locator#isLive correctly (and without too much overhead) requires doing some book-keeping (either mark entities as deleted when you delete them, or evict them from the entity cache when you delete them)

All of the above are taken care of by JPA or JDO transparently, provided you use the "open session in view" pattern.

Not that you *should* use JPA or JDO in your apps (honestly, they always caused me headaches), but for a tutorial i think you should start with them, then possibly do another one with a low-level solution. I did write an RF-based app using MongoDB as the backend and had to implement the above-mentionned entity cache, it's relatively easy but that's one more distraction from a newcomer's POV.

[Andy King]

Again, thank you for you help and observations, Thomas!

• I was not aware that, when using a batch of requests, the objects that are common to multiple requests have to be identical ... my expectation would have been that the version value would have been used to ensure that the entity was equivalent.  My first iteration of the example actually implemented a cache on the server side, and it really isn't difficult.  From your description I take it that this is only an issue if requests are batched within the same request context, in which case I may just put in a caveat and introduce a better solution later.
• Certainly the work I'd need to do to track changes to individual fields/columns would be painful (it would be nice if there was some way to leverage the work that's already been done by RF, for example, to deliver the request context to the server).
• It's true that if there is an entity cache then the Locator#isLive method will be much more efficient than if it does a "select" from the database for every entity; and certainly if I maintain an entity cache then the cache would reflect deletes.  Again, I think this only becomes an issue if multiple requests are sent in one message from the client.