Thanks for the tips on making it work with JUNIT tests. But, I have
webdriver tests that are failing. In my case, many webdriver tests give the
real experience as done by the user.
I am reading the pattern suggested by Jeff. But, it still leads to many
application wide changes in my case.
I am thinking the following approach, to limit the pain of the HRD eventual
consistency issue. It can be done along the same lines as the Objectify
CachingService. Here is my first cut.
Lets say the Class is Product. I will created another Class ProductECList
(EC - Eventual Consistency)
class ProductECList {
@Id long = 1;
Key<Product> listProductKeys;
}
1st part ObjectifyImpl put()
- Extend ObjectifyImpl put(). Check if the POJO's Class is Product. Then
get the KEY of this put entity.
- Read ProductEcList, and add to the listProductKeys and do the
put(ProductEcList)
2nd part - QueryImpl.list() for the simple case discussion.
1. Extend QueryImpl.list()
2. Do the normal Objectify list()
3. Get the listProductKeys from the ProductECList entity
4. Do a Query for the listProductKeys, and find if you get back the same
number of entities as in the list. Then you can assume you have got
entities queried in the above no 2. Then remove the keys from the
listProductKeys and persist ProductECList
5. If no entities are returned in above no 4, then get each entity by the
Key, and then check if the entity satisfies the Query conditions. If yes,
then add it to the QueryImpl.list() from above no 1.
Give your feedback please..
-Aswath
www.AccountingGuru.in
On Tue, Nov 1, 2011 at 5:01 AM, Broc Seib <broc.s...@gmail.com> wrote:
> In my unit tests for my entities using HRD, I simply switch that
> percentage completely on/off around those few places in the unit test code
> where I need my entity to become "fully committed" in order for the rest of
> the unit test to work. Yes, it is kind of contrived, but then again so is a
> unit test. I must consciously decide to flip it on/off around that bit of
> code. My unit test code looks something like this:
>
>
> //read this:
> http://code.google.com/appengine/docs/java/tools/localunittesting.html
> public class SampleUnitTest {
>
> private static boolean SHOULD_APPLY = false; // set this flag
> appropriately in the units test below.
> private static final class CustomHighRepJobPolicy implements
> HighRepJobPolicy {
> @Override
> public boolean shouldApplyNewJob(Key arg0) {
> return SHOULD_APPLY;
> }
> @Override
> public boolean shouldRollForwardExistingJob(Key arg0) {
> return SHOULD_APPLY;
> }
> }
>
> private final LocalServiceTestHelper helper = new
> LocalServiceTestHelper(new
> LocalDatastoreServiceTestConfig().setAlternateHighRepJobPolicyClass(CustomHighRepJobPolicy.class));
>
> @Before
> public void setUp() {
> helper.setUp();
> }
>
> @After
> public void tearDown() {
> helper.tearDown();
> }
>
>
> @Test
> public void test1() throws Exception {
> String orgName = "The Organization, Inc.";
> SHOULD_APPLY = true; // temporarily allow things to be written to
> datastore for real
> final OOrganization org = ODaoOrganization.create(orgName);
> SHOULD_APPLY = false; // return HRD writes back to full "failure" for
> remaining unit test
>
> // now do my unit test that needed my org entity to be properly
> persisted.
> }
> }
>
>
> Broc
>
>
>
> On Mon, Oct 31, 2011 at 3:36 PM, Jeff Schnitzer <j...@infohazard.org>wrote:
>
>> There's this:
>>
>> https://groups.google.com/d/msg/google-appengine/NdUAY0crVjg/3fJX3Gn3cOYJ
>>
>> Some thoughts:
>>
>> * I don't think there's really anything to save you from eventuality
>> except careful consideration during the design of your data model. Pick
>> your entity groups carefully and use XG transactions sparingly to move data
>> "across" when you need atomicity.
>>
>> * A lot of the time eventuality is not a big deal. On the other hand, if
>> you're building an accounting app, it probably is a big deal.
>>
>> * There's a difference between what your users experience and what your
>> tests experience. Say you have a test for "add this product to the catalog
>> and then check to see if it's in the catalog". In the real world it
>> doesn't matter if your users see the new product right away. But your
>> tests demand it immediately. The problem is with the test. I've "fixed"
>> the tests by doing this in my fixture setup:
>>
>> newLocalDatastoreServiceTestConfig().setDefaultHighRepJobPolicyUnappliedJobPercentage(0.1f)
>>
>> Unfortunately a good argument can be made that this diminishes the value
>> of the tests. Really some tests should be run with eventuality and others
>> without. Anyone know if setDefaultHighRepJobPolicyUnappliedJobPercentage()
>> can be called repeatedly after setup to switch back and forth?
>> Jeff
>>
>> On Mon, Oct 31, 2011 at 6:31 AM, Aswath Satrasala <
>> aswath.satras...@gmail.com> wrote:
>>
>>> Hi,
>>> I am trying HRD on local dev server. I have bunch of webdriver tests
>>> for different parts of my application that create entities and then doing a
>>> list of all the entities.
>>> My tests are failing in several places. It is due to the eventual
>>> consistency of the HRD. The tests run fine on M/S and on both
>>> production/local environment.
>>> I have 20-30 KINDS, and entities are created for 1-or more KINDs
>>> depending on the business logic, all in a transaction. Immediately,
>>> various reports are done. They fail.
>>>
>>> My question: What pattern needs to be followed? My application has
>>> grown very large during last 1.5 years or so. Doing re-factoring at every
>>> place in the application for eventual consistency will be a very large
>>> effort for a small team. I don't even know what extra work needs to be put
>>> to get this fixed.
>>>
>>> Am I better of sticking with M/S. So far, I have managed and designed
>>> entity relationships to work within one entity group.
>>>
>>> Are there any patterns coming out from the Objectify team to handle
>>> Eventual consistency issue of the HRD?
>>>
>>> -Aswath
>>> www.AccountingGuru.in
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Google App Engine for Java" group.
>>> To post to this group, send email to
>>> google-appengine-java@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> google-appengine-java+unsubscr...@googlegroups.com.
>>> For more options, visit this group at
>>> http://groups.google.com/group/google-appengine-java?hl=en.
>>>
>>
>>
>
--
You received this message because you are subscribed to the Google Groups
"Google App Engine for Java" group.
To post to this group, send email to google-appengine-java@googlegroups.com.
To unsubscribe from this group, send email to
google-appengine-java+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-appengine-java?hl=en.
