Returning key identifier as part of data returned by query

I use the key identifier extensively throughout my app as my "id". The namespace and kind doesn't change. Is it possible to return the key identifier inline with the data returned from queries or should I just include the identifier as a property on the entity ?

For example, if you look at this simple example of an entity returned by a query:

[ { key: { namespace: 'mynamespace', path: [Object] },data: { name: 'My Entity'} }]

What I would like is for my data object to look like:

data:{id:XXXXX,name:'My Entity}

At the moment to include the key identifier with my data object I need to do something like:

var dao = entity.data
dao.id = entity.key.path.pop()

NOTE - I use pop() here since it's in the examples but I think it's a bad idea. Poping the identifier removes it from the path array. If I go on to reuse the key, it's incomplete (e.g. if I did a get and update). I think entity.key.path[entity.key.path.length - 1] is a better idea.

Anyway, if I am returning thousands of entities I can write (using async.js) something like:

 ds.runQuery(query, function(err,entities){
   async.map(entities,DAO,callback);
 });

function DAO(entity,callback) {
  var dao = entity.data;
  dao.id = entity.key.path.pop();
  callback(null, dao);
}

The problem I have is that (1) this is quite cumbersome (2) I haven't benchmarked but I'm sure there is a performance hit.

Is there a better way to do this ?

Some related issues:

Provide helper methods on entity.Key for Kind, parent, name, and ID #574 - Add helper methods on key (this would make your code dao.id = entity.id (or dao.id = key.name)
Access properties directly from the entity #508 - Access properties directly rather than inside data / id

I think #574 would solve your issue.

Regarding key.path.pop(): I can't find anything in the docs -- can you maybe open a separate issue to remove those examples? I think you're right that it's not the best way to get the Key name/id.

@jgeewax

Thanks @jgeewax!

My specific issue refers to retrieving entities. I actually think getting the id is ok when saving an entity as it's only one entity. The problem is that retrieving multiple entities requires something like map to populate the data object.

This could be resolved by automatically populating the id or name property on the data object returned. This is similar to what happens in MongoDB whereby the _id is automatically set. If you want to exclude to exclude the id or name property you could do so through a projection, but by default it's included.

@byrneciaran

Gotcha, @byrneciaran

Our worry (outlined in #508) is that key isn't a reserved word, so if someone had a property called key, we'd blast it out with the entity key... So we have to figure something out there... Feel free to add your use case over on that issue so we can make sure whatever we decide makes sense for everyone!