RenameProperty causes adding extra columns to fail

[koscejev]

Considering MyPojo has two fields ts and action, the following fails on the last line:

    CsvWriter.CsvWriterDSL<MyPojo> csvWriterConfig = CsvWriter.from(MyPojo.class)
      .columns()
      .column("ts", new RenameProperty("timestamp")) // OK
      .column("action"); // fails on this line

The exception:

org.simpleflatmapper.map.MapperBuildingException: Could not find eligible property for 'timestamp' on  class my.pojo.MyPojo not found  See https://github.com/arnaudroger/SimpleFlatMapper/wiki/Errors_PROPERTY_NOT_FOUND

	at org.simpleflatmapper.map.error.RethrowMapperBuilderErrorHandler.propertyNotFound(RethrowMapperBuilderErrorHandler.java:26)
	at org.simpleflatmapper.map.mapper.PropertyMappingsBuilder$1.accept(PropertyMappingsBuilder.java:65)
	at org.simpleflatmapper.map.mapper.PropertyMappingsBuilder$1.accept(PropertyMappingsBuilder.java:62)
	at org.simpleflatmapper.map.mapper.PropertyMappingsBuilder.handleSelfPropertyMetaInvalidation(PropertyMappingsBuilder.java:138)
	at org.simpleflatmapper.map.mapper.PropertyMappingsBuilder._addProperty(PropertyMappingsBuilder.java:106)
	at org.simpleflatmapper.map.mapper.PropertyMappingsBuilder.addProperty(PropertyMappingsBuilder.java:73)
	at org.simpleflatmapper.map.mapper.AbstractConstantTargetMapperBuilder.addColumn(AbstractConstantTargetMapperBuilder.java:85)
	at org.simpleflatmapper.map.mapper.AbstractConstantTargetMapperBuilder.addColumn(AbstractConstantTargetMapperBuilder.java:72)
	at org.simpleflatmapper.csv.CsvWriter$CsvWriterDSL.newColumnMapDSL(CsvWriter.java:400)
	at org.simpleflatmapper.csv.CsvWriter$CsvWriterDSL.column(CsvWriter.java:309)

[arnaudroger]

just seen that sorry for not coming back on it earlier

[arnaudroger]

what is the structure of MyPojo?
I don't know if I ever check rename property work for writing will add a test and check

[koscejev]

I tried this with different structures, it doesn't seem to be related to the actual fields.

It seems that rename property is applied initially one way, but when it needs to be "reapplied" (because columns are copied when a new one is added), it's not done fully and the fields are checked against original names, not against renamed ones.

That's just my understanding so far, couldn't investigate in detail. In the end I only did a PoC and had to switch to a different project because of this.

[arnaudroger]

I'm just trying to understand what you where trying to do
is ts in the pojo and you want the column name to be timestamp?

[arnaudroger]

so just tried by assuming the prop in the object would be ts.

    public static class Pojo461 {
        public final long ts;
        public final String action;
    }

the rename property in that context will actually tell it what is the name in the object.
so here you are saying that "ts" is the output columnname but it actually map to "timestamp"

timestamp does not exists so it does some speculative property mapping and link the column to the actual pojo.toString object.
but when you add another column it backtrack has obiviously that was the wrong choice and throw the exception on timestamp at that time.

RenameProperty was introduce initially on the reading side and the semantic is not really clear there it should actually contains the actual property name.

so if you write

        CsvWriter.CsvWriterDSL<Pojo461> csvWriterConfig = CsvWriter.from(Pojo461.class)
                .columns()
                .column("timestamp", new RenameProperty("ts")) // OK
                .column("action"); // fails on this line
        
        StringBuilder sb = new StringBuilder();
        csvWriterConfig.to(sb).append(new Pojo461(1, "add"));

        System.out.println("sb = " + sb);

it works and prints

timestamp,action
1,add

[arnaudroger]

I'm adding some javadoc on the RenameProperty to make that clearer.
and will add some doc too.

[koscejev]

Indeed, looking at your example, I was applying it in the opposite direction. I had property ts and wanted to write it out as timestamp. The new javadoc makes it more clear, nice!

However, in that case I'm surprised it failed on the next column, not the ts column, when I used what is basically an invalid property name. May I suggest also a negative test case that should result in immediate failure when RenameProperty references a non-existing bean property?

[arnaudroger]

not a bad idea, no point trying to speculate when the RenameProperty should be an exact match