AppEngine allocateIdRange:澄清有关CONTENTION状态 [英] AppEngine allocateIdRange : clarification about CONTENTION state

查看:112
本文介绍了AppEngine allocateIdRange:澄清有关CONTENTION状态的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我将实体从一种复制到另一种,并且想要以可预测的方式映射它们的 long id。映射结束后,我希望自动生成ID。



为了保护我复制的实体,我想使用 allocateIdRange 并手动分配每个ID,因为我复制它。我希望这会导致数据存储保护这些新的ID,并且只将其他ID分配给复制后创建的新实体。



一个返回代码让我担心: CONTENTION


表示给定的KeyRange为空,但数据存储的自动ID
分配器可以在此范围内分配新的实体密钥。然而,如果以下
中的任何一个为真,那么在这个范围内手动分配Keys是
安全的:


  1. 没有其他请求会插入具有相同类型的实体,
    parent作为给定的KeyRange,直到写入了从此范围内手动分配
    键的所有实体。


  2. 使用与给定的KeyRange类型和父类相同的其他请求覆写的实体是可以接受的。

  3. >

    2号是我的。这些实体被覆盖是不可接受的。

    1我认为是可以接受的,但措辞足够可怕,我想确认。如果我分配5个ID,从 100 104 ,并且我得到 CONTENTION 后面,这似乎表明我将复制的实体可能会被未来使用自动ID的新实体覆盖。但是,如果我快速编写自己的手动设置为100,101,102,103和104的实体,我将是安全的,并且具有自动ID的新实体将不会收到这些ID。



    我很担心,因为我不明白这是如何工作的。我不认为id分配器会关注写入内容。

    TL; DR



    想象一下以下场景:

      allocateIdRange(100,104); //返回CONTENTION 
    putEntityWithManualId(100);
    putEntityWithManualId(101);
    putEntityWithManualId(102);
    putEntityWithManualId(103);
    putEntityWithManualId(104);
    //全部投入成功

    现在,当我稍后调用

      putNewEntityWithAutomaticId(); 

    是否存在自动编号为100,101,102,103或104的风险?

    解决方案

    文档如下:


    数据存储区的自动ID分配器不会将键分配给将覆盖现有实体的新实体,因此一旦范围填充后就不再存在争用。


    因此,您不必担心新复制的实体会被覆盖。


    I'm copying entities from one kind to another, and want to map their long ids in a predictable way. After the mapping is over, I want auto-generation of ids to kick in.

    To protect the entities I copy, I want to use allocateIdRange and manually allocate each id as I copy it. My hope is that this will cause the datastore to protect these new ids, and only assign other ids to new entities created after the copy.

    One return code has me worried: CONTENTION

    Indicates the given KeyRange is empty but the datastore's automatic ID allocator may assign new entities keys in this range. However it is safe to manually assign Keys in this range if either of the following is true:

    1. No other request will insert entities with the same kind and parent as the given KeyRange until all entities with manually assigned keys from this range have been written.

    2. Overwriting entities written by other requests with the same kind and parent as the given KeyRange is acceptable.

    Number 2 is out for me. It is not acceptable for these entities to be overwritten.

    Number 1 I think is acceptable, but the wording is scary enough that I want to make sure. If I allocate 5 ids, from 100 to 104, and I get CONTENTION back, this seems to indicate that the entities I copy MAY be overwritten with new entities with automatic ids in the future. BUT, if I hurry up and write my own entities with ids manually set to 100, 101, 102, 103, and 104, I will be safe and new entities with automatic ids will NOT receive these ids.

    I'm worried because I don't understand how this would work. I don't think of the id allocator as paying attention to what gets written.

    TL;DR

    Imagine the following scenario:

    allocateIdRange(100, 104); // returns CONTENTION
    putEntityWithManualId(100);
    putEntityWithManualId(101);
    putEntityWithManualId(102);
    putEntityWithManualId(103);
    putEntityWithManualId(104);
    // all puts succeed
    

    now, when, later, I call

    putNewEntityWithAutomaticId();
    

    is there any risk that the automatic id will be 100, 101, 102, 103, or 104?

    解决方案

    The documentation follows as bellow:

    The datastore's automatic ID allocator will not assign a key to a new entity that will overwrite an existing entity, so once the range is populated there will no longer be any contention.

    Thus, you don't need to worry that your newly copied entities will be overwritten.

    这篇关于AppEngine allocateIdRange:澄清有关CONTENTION状态的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆