LC-501: standardize stage properties to camelCase

[Jozurf]

No description provided.

[rseitz]

We do need a unit test for this. Can be a simple test that runs the conversion on one input conf file and confirms that the output matches what we expect. The conf file should have some examples of edge cases like multiple instances of the same stage property name on one line (used as a property and as a value) and some other snake case properties in connectors or elsewhere that shouldn't be converted because they're not stage properties

[Jozurf]

WIP

[Jozurf]

created test for this in 1134f0a

[spencersolomon6]

[question] Should these document field names be camel case too?

[Jozurf]

@kiratraynor to answer both of your questions. I did have the same thoughts, and short answer is, that we can, but this would make it a nightmare to create a script for conversion. Some external libraries (like Tika for TikaExtractor) produces snake_case for lucille documents. And so any other stages further down the pipeline that takes in the name of the field (like source: "field_produced_by_tika") cannot be changed in the script convertor. Also, there is the case where CSVConnector, SolrConnector, VFSConnector, DatabaseConnector could produce fields with snake_case, meaning that the script would have to know which fields not to convert in cases like this, especially for CSVConnector and DatabaseConnector, which is dependent on the input.

[kiratraynor]

I'm not sure if we'd want to change these or not, but there are a few examples of stages that have values that are in snake case like NormalizeText (with title_case, sentence_case), ChunkText (with the doc fields its adding), Condition (with 'must_not'), or just run_id in general. It seems like the changes that were made were ensuring that the stage properties themselves were in camel case, but just wondering if we would we want the values like these to be as well so that it's more consistent?