search

Patreon / patreon-java

Interact with the Patreon API via OAuth
Apache License 2.0
52 stars 26 forks source link

Camel/Snake case inconsistency in Pledge class is breaking Java Spring Integration #24

Open decmurphy opened 5 years ago

decmurphy commented 5 years ago

I'm trying to make API calls to get all of my campaigns pledges and then cache them for some time on my server, so as to avoid querying the Patreon servers too much. I'm storing the JSON results of

fetchAllPledges(String campaignId) and the Rewards subsection of fetchCampaigns()

in a MongoDB database, and using Spring Repositories to save to and to read from the database.

Spring makes assumptions about variable names based in Java convention. If a field name is amount_cents, it will call a getter getAmount_cents(). If that field name is amountCents, it will call getAmountCents(), and so on.

For some reason, the member variables of the Pledge class are camelCase, even though the variables entered into the constructor are snake_case. This isn't the situation in, for example, the Reward class where both the member variables and the constructor parameters are in snake_case and Spring performs perfectly.

Petition to modify the member variables of Pledge to use a consistent case scheme. Spring doesn't care which scheme is used, as long as there is consistency.

nperickson commented 5 years ago

Hey @murphd37,

I talked with the team and it sounds like what you're asking for is already possible without us needing to change anything. A suggestion made by one of my engineers was that you could wrap our whole class in bean with names of your choosing. That should fix it without needing to reconfigure Spring.

decmurphy commented 5 years ago

Hi @nperickson,

Thanks for the response! That's actually what I'm doing, believe it or not, and yes it works. So my issue is far from a burning one. But it's more of a workaround than a fix, don't you agree?

I wouldn't say that changing the case of some private variables needs an immediate fix and deploy, because it's obviously not critical. But it seems like such a trivial task that will not only confirm to Java conventions but also make easier the life of anyone trying to integrate this project with a Java Spring project.

I'm happy to submit a PR for this, if you think there's a possibility of it being merged.

decmurphy commented 5 years ago

Hi @nperickson - any thoughts on the above? As I say, I'm happy to submit a PR.

Thanks!