interesting! thanks for the writeup, tav, and for the discussion,
julian and andy. this is definitely a worthwhile use case.
short answer: without getting too deep into the different use cases, i
agree with andy. this is a great feature, and would almost certainly
be useful in a library or the ap
> Would require an additional check in the if/else clause on write of
> the related entity which should raise an error if the entity it points
> to doesn't exist...
That's not enough - the __index__ entity could be deleted afterwards.
The relevant check in deletes is very expensive (it's a query
Hey Andy,
> Cute, but there's no way to guarantee that there's an object with that
> key.
Very good point!
Would require an additional check in the if/else clause on write of
the related entity which should raise an error if the entity it points
to doesn't exist...
And if all entities that wer
> With my proposal, when an entity is indexed, the key defined in its
> __index__ property will be used in place of its own key when the
> indexes are constructed...
Cute, but there's no way to guarantee that there's an object with that
key.
Also, redirecting queries this way means that there's
Hey Julian,
> That's an interesting idea, for that particular use case.
>
> If I reformulate the "relation index entities" query as I understand
> it:
> 1. [datastore]Traverse the index and return entity keys
> 2. [app engine]Transform returned keys to retrieve parent entity
> 3. [datastore] Batc
That's an interesting idea, for that particular use case.
If I reformulate the "relation index entities" query as I understand
it:
1. [datastore]Traverse the index and return entity keys
2. [app engine]Transform returned keys to retrieve parent entity
3. [datastore] Batch get of entities
Your id
