Support put for parameters of type FullEntity<IncompleteKey> in v1beta3

No description provided.

@aozarov

Is this really necessary? The behavior of add and put for incomplete keys kind of overlaps in my mind, am I wrong? Isn't add(FullEntity<?>... entities) already enough to handle the creation of entities with incomplete keys?

If we must support this then we should also change put signature to

List<Entity> put(FullEntity<?>... entities)

so that we return the generated complete keys (this might be a bit counter-intuitive as we remove duplicates from input entities, hence returned entities do not necessarily match the input). Thoughts? /cc @aozarov

In v1beta2* the datastore forced separating the entities with non complete keys which could only be used for add operations. v1beta3 now allows to specify incomplete keys also for put operations.

A user can mimic this by (1) in the program separate the entities that are incomplete and use them in add instead of put (2) use batch to allow committing it in 1 RPC. However, that require some boilerplate code which now could be avoided.

I don't think this issue is a high priority, but worth fixing when possible.
Yes, in that case the put should return a List<Entity> similar to add.
Also, DatastoreBatchWriter will need to support it by either adding
putWithDeferredIdAllocation or decoupling DatastoreBatchWriter from DatastoreWriter.

A user can mimic this by (1) in the program separate the entities that are incomplete and use them in add instead of put (2) use batch to allow committing it in 1 RPC. However, that require some boilerplate code which now could be avoided.

I see. I just wanted to understand the reason for this.

In put now we remove duplicates in the input entities, should the returned list of updated/added entities have the cardinality (and order) of the input or of the input-without-duplicates? Both ways might seem a bit strange at first.

We should return the list of entities matching the order of the input.
De-dup is an internal implementation detail and should only apply to entities with complete keys (obviously) and the same result should be associated with all the entities with matching keys.