What advantage is there to designing child-parent relationships, which allow us to do writes in transactions, when there is never a real concern for consistency and contention and those sort of more complex issues? Does it make writes and reads faster?
Consider my situation where there are many .png images that are referenced to one mosaic layer, and these .png images are written just once by a single user. The user can design many mosaic layers and her mosaic layers and referenced image entities are never changed/updated, they are just deleted some time in the future. Other users can come to the web project site and interactively view the mosaic layer as different layouts/configurations of the images as they play (query) with different criteria. So reads should be very fast.
So there is no real worry of contention, or users conflicting with one another with writing new image entities. And because of that I am assuming there is no “requirement” for the .png image entities to be grouped by their same mosaic layer in child-parent relationship.
However, perhaps, since the documentation says they are stored close to one another, if the many image entities were grouped as children to a single mosaic layer parent than this has the advantage that the writing (in transaction) and reading will happen much faster?
After searching the google app engine user group with “speed writes transactions” I learned that transaction do NOT provide a speed increase and may actually decrease speed. So they are only to be used when specifically needed, not to be used to try to get speed gains.