Support ID and name on the same kind

[GoogleCodeExporter]

There may be cases where some of the entities of a kind have numeric ID and 
other have a string name (probably most relevant during migration), which make 
it impossible to use with Objectify. I propose changing Objectify to behave as 
follows:
- If @Id is present on a String property and it is null when saving - act as if 
it was Long - use the datastore ID generation.
- If @Id is present on a String property and the loaded entity has a numeric 
ID, set the property to the ID's toString() value.

Original issue reported on code.google.com by guz...@gmail.com on 24 Oct 2014 at 10:59

[GoogleCodeExporter]

This first idea is horrible - it makes it easy to accidentally shove mismatched 
id types into your database. Sorry.

The second id is not bad. This feels like something that should be opt-in 
behavior, though, something like @Id(typeConvert=true).

You should never, _ever_ have a mix of string and numeric ids for a kind. This 
is a strong indicator of database corruption (and/or extremely poor programming 
practices). However, I can see how you might want some sort of bailout when 
something bad does happen.

Original comment by lhori...@gmail.com on 27 Nov 2014 at 7:19

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

To clarify, this is entirely meant for migration, not a permanent model. I have 
no desire to have numeric and String IDs in the same kind except for the 
duration of migration from one ID type to the other. Maybe this could be added 
to the functionality of @AlsoLoad somehow.
I already started my migration with Objectify as it is now and it's not that 
difficult, so I'm not really sure now that such feature would be really 
essential. Maybe wait for additional input from the community before deciding.

Original comment by guz...@gmail.com on 1 Dec 2014 at 11:34