It is probably also possible if you are creating new entities at the same time something else is deleting them.
For example: user A -> starts request to add new child. user A -> new child entities created, BUT not yet put. user B -> starts request to delete parent. user B -> parent is deleted. user A -> new children put. The parent does not have to exist for a child entity to be put. Robert On Wed, Aug 25, 2010 at 08:54, djidjadji <[email protected]> wrote: > There is a small time slot between the object written to the datastore > but the index tables are not updated yet. > If you perform a get in a *concurrent request* in this time slot you > get a None value back. > If you do the get in the same request that does the put(), you will > get the object back because put() only returns when the index tables > are updated. > > 2010/8/25 johnP <[email protected]>: >> In a similar vein, is it possible for a query to mistakenly return a >> None? In the past year, I have had two or three instances when I lost >> data integrity, and believe it might be based on a mistaken query >> return. The situation is I have a Parent object and some Children >> objects. If a user wants to delete the Parent, then I run a test: >> >> cannot_delete = models.Children.all().filter('parent =', parent).get() >> if cannot_delete: >> return Cannot Delete >> else: >> delete Parent >> >> Like I said, in the past year I've had one or two cases where Occam's >> Razor tells me that the Parent was deleted because the test returned >> None (rather than raising a TransientError or something of that sort) >> when there were indeed Children objects. Is it conceivable that the >> datastore may have mistakenly returned a None for a get()? >> >> johnP >> >> >> On Aug 24, 5:49 pm, "Nick Johnson (Google)" <[email protected]> >> wrote: >>> Hi Vitaly, >>> >>> When a transaction commits, the data has been written to several disks in a >>> single datacenter. Thus, no one hardware failure can cause data to be lost. >>> Shortly thereafter, your data is replicated to other locations, providing >>> security against anything that affects a whole location. In theory, you >>> could lose data if something really drastic happened to a datacenter >>> immediately after a write but before replication - but this is extremely >>> unlikely! >>> >>> If you're worried about unnoticed dataloss, I can assure you this is not >>> possible - if data is lost, we would be fully aware of it, and taking steps >>> to recover it if possible. >>> >>> -Nick Johnson >>> >>> On Sun, Aug 22, 2010 at 10:08 AM, Vitaly <[email protected]> wrote: >>> > Hi, >>> >>> > Can I be sure that data in App Engine's datastore will not be lost >>> > after successful transaction commit? Is it possible that some recent >>> > changes to database will be lost if hardware failure occurs before >>> > replication to another datastore server is finished? >>> >>> > Thanks, >>> > Vitaly > > -- > You received this message because you are subscribed to the Google Groups > "Google App Engine" group. > 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-appengine?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. 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-appengine?hl=en.
