Jooq mapping issue from #572

[arnaudroger]

@anuraaga just created a separate ticket

Hi @arnaudroger - I tried running this version of the mapper and mappers that used to work with JOOQ and sfm stopped working. Is it expected? Let me know if there's any other info I can provide.

 Caused

 by: org.simpleflatmapper.map.MapperBuildingException: Could not find Getter for 
 JooqFieldKey{field="stellarstationdb"."user"."id", index=0} returning type class com.stellarstation.userservice.api.UserProfile path {this}. See https://github.com/arnaudroger/SimpleFlatMapper/wiki/Errors_CSFM_GETTER_NOT_FOUND
  at org.curioswitch.common.server.framework.database.DatabaseUtil$1.accessorNotFound(DatabaseUtil.java:45)
  at org.simpleflatmapper.map.mapper.PropertyMappingsBuilder._addProperty(PropertyMappingsBuilder.java:106)
  at org.simpleflatmapper.map.mapper.PropertyMappingsBuilder.addProperty(PropertyMappingsBuilder.java:69)
  at org.simpleflatmapper.map.mapper.DefaultConstantSourceMapperBuilder.addMapping(DefaultConstantSourceMapperBuilder.java:160)
  at org.simpleflatmapper.jooq.JooqMapperBuilder.addField(JooqMapperBuilder.java:65)
  at org.simpleflatmapper.jooq.SfmRecordMapperProvider.provide(SfmRecordMapperProvider.java:53)

[arnaudroger]

@anuraaga so I'm assuming you have a UserProfile object with an id field? what's the type of the id field in the UserProfile object? is it constructor injected? what's the setter or constructor signature? in the jooq query have the field="stellarstationdb"."user"."id" what type and datatype is that?

Thanks for the report. I think it might be a conversion issue but won't know for sure until I can reproduce.

[anuraaga]

Thanks for filing the issue, sorry for not following up with more details. I'll be able to provide more details about the data structure tomorrow. But thanks to your comment, I can provide some quick details about the code. The mapping code we use is this

https://github.com/curioswitch/curiostack/blob/master/common/server/framework/src/main/java/org/curioswitch/common/server/framework/database/DatabaseUtil.java

It is very common to map into a smaller type from a bigger one so we disabled the property check. But it seems that with the recent change, the accessor exception is being triggered for this case where the target type is smaller than the source. Does this mean we should disable the accessor check too?

[arnaudroger]

Thanks makes a lot of sense. In that case it should call a property not found. I’ll send you the code so that you don’t even have to have an error handler. I don’t think I need more details anymore cheers Sent from my iPhone

On 6 Jan 2019, at 11:38, Anuraag Agrawal notifications@github.com wrote:

Thanks for filing the issue, sorry for not following up with more details. I'll be able to provide more details about the data structure tomorrow. But thanks to your comment, I can provide some quick details about the code. The mapping code we use is this

https://github.com/curioswitch/curiostack/blob/master/common/server/framework/src/main/java/org/curioswitch/common/server/framework/database/DatabaseUtil.java

It is very common to map into a smaller type from a bigger one so we disabled the property check. But it seems that with the recent change, the accessor exception is being triggered for this case where the target type is smaller than the source. Does this mean we should disable the accessor check too?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[arnaudroger]

just pushed 6.1.1 to maven central should be available in 20-30mn. the fix should restore the previous error handling behavior. you can also use

SfmRecordMapperProviderFactory.newInstance().ignorePropertyNotFound().newProvider();

that will mark any column as optional and not fail if it can't map it.

[anuraaga]

Thanks for the fix and the sample code!