Preserve casing of field names

[Illapikov]

We used 0.3.7 version and tried to update to newest(0.4.2) version.
Schema look like:

"ABC": {
    "title": "ABC" ...
}

Generated sources was (0.3.7):

@JsonProperty("ABC")
private Integer ABC;

Generated sources are (0.4.2):

@JsonProperty("ABC")
private Integer aBC;

We use mongo to store our data.
In mongo it was (0.3.7):

"ABC" : 100

In mongo it is (0.4.2):

"aBC" : 100

So mongo mapper tried to find ABC field in java class and we are losing all data, which generated before update.

Possible solution: if property name all in uppercase left it without replacing first to lowercase.
Related to: #126

[dimas]

The best would be not to touch field names at all. Or at least provide a command line switch that allows some backward-compatible mode.

[dimas]

@joelittlejohn, do you have an opinion on this one? This is kind of blocker for us - we cannot upgrade to the latest version as it breaks compatibility with the previous...

[joelittlejohn]

I see the problem here, but I'm concerned that you're treating the private field names as a public interface. The contract here is defined by the public members and the annotations present on those members.

Putting that aside for now, I guess there are a couple of options here:

• Revert the changes made for JSON schema with enum member with a name starting with a capital letter, causes a generation of a code that doesn't compile #126, either leaving that as a known issue or introducing some alternative fix
• Add a config option to switch between the two modes, this will certainly provide you some relief but it's going to be a very strange and specific config option.

One thing that surprises me is that your Mongo library doesn't appear to understand Java Bean conventions. Which ORM library are you using to interact with Mongo?

[dimas]

We are using spring and spring-data. The mongo library is:

            <dependency>
                <groupId>org.springframework.data</groupId>
                <artifactId>spring-data-mongodb</artifactId>
                <version>1.2.1.RELEASE</version>
            </dependency>

While I agree that we should not be relying on any of the private field names, I also think that it makes sense to preserve names as they are in the JSON schema. When if "FTP" is not a proper field name in a Java class, "fTP" is even worse.

Speaking of #126 - I see you discussed lots of different options before choosing to lowercase the first letter. But one I think was overlooked - what if enum is called TimeFormat while the field of that type will be timeFormat?

Thanks

[joelittlejohn]

what if enum is called TimeFormat while the field of that type will be timeFormat?

Not sure I understand what you mean here. Can you elaborate? #126 involves a field, and enum, called TimeFormat.

[joelittlejohn]

I think I'll investigate whether it's possible to use the fully qualified naming fix with CodeModel. This would solve #126 and allow us to leave these names alone.

[ctrimble]

@Illapikov I have had a lot of success using Jongo with the class files generated by this project. It uses Jackson to map objects into Mongo BSON, so you get the names in the binding annotations, instead of the bean names. The project is also super receptive to patches, so you can get changes in if you need them.

[joelittlejohn]

I can second @ctrimble's recommendation. I've used Jongo on the most recent projects I've worked on (the ones that combine Java and Mongo anyway) and it's by far the best API for persistence & data-binding for Mongo that I have found.

[dimas]

While Jongo seems to be a nice library, it would be a huge change from what we have at the moment. We will have to replace all the repositories generated for us by spring data (http://docs.spring.io/spring-data/data-commons/docs/1.6.1.RELEASE/reference/html/repositories.html) which we then extensively customized with some lower-level code.
While not impossible change, it is just too big given how many places already depend on the current framework.

[joelittlejohn]

@dimas One to bear in mind for your next project maybe, but I can certainly understand that it may not be a viable change for you to solve your current problem. Don't worry, I still intend to look at an alternative fix for #126 that will allow us to leave the casing of fields alone.

[dimas]

And thanks a lot for that! )

[ctrimble]

@dimas, one other thought. The spring mapping documentation states that they support a @Field annotation. You could inject those with a custom annotator. This would have the same effect that Jackson annotations have with Jongo.

[dimas]

@ctrimble, interesting, thanks.
We may play with this one. But I would only prefer using it as the last resort because it will require bringing Mongo dependency to the module which has all the POJOs (built from JSON). Given that that module is also used by client apps which have no knowledge of Mongo at all, it is probably not the nicest solution for us.