Support versioning of json files.

[GoogleCodeExporter]

The current approach of @Until and @Since doesn't work as it only deals with 
versioning from the perspective of the current code.  If I wrote out a json 
stream with version 1.0 code and version 2.0 code has that version as a 
different type, this will fail. 

A couple of parts need to change:

1) There needs to be some concept of 'type' (eg json:type) associated with each 
element.  This would also resolve the problem of deserializing polymorphic 
collections.  I have implemented this explicitly but it really should be built 
into the framework rather than having to register type adapters for each 
abstract super class.  I believe this issue is already in the queue, but I view 
it as a requirement for #2.

2) There needs to be a version id of the type that has been stored (eg 
json:version).  When the parser reads the data, it should be able to lookup the 
adapter per type/version pair that can correctly deserialize the json stream.

Original issue reported on code.google.com by swall...@gmail.com on 21 Jan 2011 at 4:54

[GoogleCodeExporter]

Adding type and version information to JSON objects slightly defeats much of 
the motivation of JSON: high signal to noise ratio.

We may consider this but if you really need type safety and versioning you 
might be better off with a more complex wire protocol like protobuffers or 
thrift.

Original comment by limpbizkit on 22 Jan 2011 at 2:19

• Added labels: Priority-Low, Type-Enhancement
• Removed labels: Priority-Medium, Type-Defect

[GoogleCodeExporter]

I understand it's not for every use case.  My use case is JSON as a document 
storage format.  So as the code changes, the document schema will evolve and 
type and version information (where appropriate) is required to keep the latest 
code clean of old schema information.

Original comment by swall...@gmail.com on 24 Jan 2011 at 3:40

[GoogleCodeExporter]

There are security issues with carrying type information in the data, and 
trusting it on the receiving end. With Gson, we want to discourage such 
potential security holes. 

May be you should have an explicit field called type but use that to mean 
"type/version of the document" instead of the actual Java type.

Original comment by inder123 on 24 Jan 2011 at 10:25

[GoogleCodeExporter]

How about tagging the entity version outside of the JSON data?

For example, web services and API, the version is usually within the URL
For file systems, add the version on the file name (or as part of the directory 
structure)
For some database storing a blob (or clob), store the version within the same 
record as the data.

Original comment by joel.leitch@gmail.com on 26 Apr 2011 at 11:26

[GoogleCodeExporter]

I don't think we want to fix this in-framework. If you want to add a version 
property to your top-level object, you should be able to accomplish what you 
want.

Original comment by limpbizkit on 30 Dec 2011 at 6:49

• Changed state: WontFix