Hi Christian,

If Nichole's tip doesn't help you, then for your list view, you could
back it up with an array (in memcache?). Upon any create, edit, delete
operation, you will have to test the relevant entity (using logic
equivalent to your query) to see whether its entry in the array should
be added, edited or removed.

You would have to think about whether you want subsequent updates by
other users or your system should be reflected at once or if a
snapshot at first list view would suffice.

(Note that for postings to this group, there is a delay of a few tens
of seconds before a new post is visible in the list. That is OK for a
technical forum, but I see that this is unacceptable for your app.)

Good luck!

Ian


On Sep 30, 7:49 am, Nichole <nichole.k...@gmail.com> wrote:
> use the level 2 cache?
>
> <property name="datanucleus.cache.level2.type" value="javax.cache" />
>
> "Objects are placed in the L2 cache when you commit() the transaction
> of a PersistenceManager. This means that you only have datastore-
> persisted objects in that cache. Also, if an object is deleted during
> a transaction then at commit it will be removed from the L2 cache if
> it is present."
>
> http://www.datanucleus.org/products/accessplatform/jdo/cache.html#level2
>
> On Sep 29, 3:59 am, "nicanor.babula" <nicanor.bab...@gmail.com> wrote:
>
>
>
>
>
>
>
> > Hi Ian,
>
> > Thanks for sharing your strategy.. I am not sure if I understand exactly how
> > could I use your system to solve my problem. Actually, the memcache concept
> > is working nice solving similar, but simpler situations. I think I explained
> > poorly my situation. Here it is:
>
> > An application manages contacts. It actually has thousands of them. On the
> > GUI side we have a listview, an editview and a createview. The list view has
> > 4 columns, and is paged (30 records per page) and by default is sorted
> > ascending by the first column. I can search the listview by issuing queries
> > serverside (I want the results always ordered and paged accordingly).
> > Now, a user clicks on "new contact". The application goes into createView.
> > Data input then save. Application goes to list view. The contact should have
> > been in the first page, but it isn't. After a few seconds, it appears.
>
> > The previous example with phone numbers is kind of the same issue, but with
> > simpler queries:
> > User modifies a contact by adding some phone numbers. Hits save and goes to
> > list view, then he remembers that one number was wrong and goes back to
> > editing the same contact. The phone numbers inserted seconds ago aren't
> > there. In this case, (since for other reasons I the phone numbers entities
> > cannot be children of the contact entity) every phone number entity has a
> > property called "contactId" that points to the father contact. The solution
> > employed in this simple case is storing in the memcache the phone numbers by
> > using contact-based keys so that for example
> > [code]
> > memcache.get("MEMCACHE_phones_contactId_1234")
> > [/code]
> > would give me an all the phone numbers for contact having id=1234. Somehow
> > (too long and boring to explain how) I manage to keep this array always up
> > to date so when the user returns lightning-fast to the editview the newly
> > inserted phone number are there, only that they are read from the memcache.
> > Analogically, how could this be done for the fore-mentioned listview
> > situation, where the query is much more complex?
>
> > Hope I didn't confused you more..
>
> > Thanks,
> > Cristian

-- 
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.

Reply via email to