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.
On Thursday, November 22, 2012 1:49:59 AM UTC-7, Thomas Broyer wrote:
>
>
> 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<http://greatlogic.com/?p=223>.
>> If you didn't go through the first tutorial, which is here: A GWT
>> Request Factory Journey <http://greatlogic.com/?p=33>, 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.
>
--
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/google-web-toolkit/-/egcm62CE0UoJ.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.
