Mapping for sqlinsertclause based upon annotations #42

Closed
manfreddev opened this Issue Nov 8, 2011 · 4 comments

Comments

Projects
None yet
3 participants
@manfreddev

Currenty, the populate method of the sqlinsertclause makes mappings based upon bean property names.
If there would be a possibility to do the mapping based upon property annotations, then the bean property names and the physical table field names don't need to match. This gives extra flexibility.

A suggested system would be to have some kind of "Mapper" system that lets you map between bean properties and the physical fields with custom mapping if required, and one implementation that is based upon annotations

SQLInsertClause.populate(Object aBean, BeanMapper aBeanMapper)

Where you have ...

PropertyBasedBeanMapper
AnnotationBasedBeanMapper
MyCustomCodedBeanMapper

This would give most flexibility.

https://groups.google.com/forum/#!topic/querydsl/UNU34YPsmZw

@luisfpg

This comment has been minimized.

Show comment
Hide comment
@luisfpg

luisfpg Nov 9, 2011

This would be quite nice... Also, I don't foresee any implementation drawbacks.
I just don't know if BeanMapper is a good name, the idea is to transform an input into a set of clause.set(alias.column, value).
It could also be used for update clauses.
Another usage I can imagine is another custom implementation for something like Hibernate's select-before-update, to only generate updates on actually changed columns. For people using DB triggers, for example, the lowest is the number of updated columns, the better. Also would prevent updates when no columns have been changed.
Anyway, my +1

luisfpg commented Nov 9, 2011

This would be quite nice... Also, I don't foresee any implementation drawbacks.
I just don't know if BeanMapper is a good name, the idea is to transform an input into a set of clause.set(alias.column, value).
It could also be used for update clauses.
Another usage I can imagine is another custom implementation for something like Hibernate's select-before-update, to only generate updates on actually changed columns. For people using DB triggers, for example, the lowest is the number of updated columns, the better. Also would prevent updates when no columns have been changed.
Anyway, my +1

@timowest

This comment has been minimized.

Show comment
Hide comment
@timowest

timowest Nov 19, 2011

Member

I just added a basic sketch for it. There are currently only two supplied Mappers : DefaultMapper which uses reflection and BeanMapper which uses a commons collections BeanMap. Take a look and try to write your own.

Member

timowest commented Nov 19, 2011

I just added a basic sketch for it. There are currently only two supplied Mappers : DefaultMapper which uses reflection and BeanMapper which uses a commons collections BeanMap. Take a look and try to write your own.

@timowest

This comment has been minimized.

Show comment
Hide comment
@timowest

timowest Nov 20, 2011

Member

I added a third one. Here are the descriptions

  • DefaultMapper - property name based, does reflection based field inspection
  • BeanMapper - property name based, does Java Bean inspection, doesn't work without accessors
  • AnnotationMapper - uses @column annotations
Member

timowest commented Nov 20, 2011

I added a third one. Here are the descriptions

  • DefaultMapper - property name based, does reflection based field inspection
  • BeanMapper - property name based, does Java Bean inspection, doesn't work without accessors
  • AnnotationMapper - uses @column annotations

timowest added a commit that referenced this issue Nov 20, 2011

@timowest

This comment has been minimized.

Show comment
Hide comment
@timowest

timowest Dec 12, 2011

Member

Released in 2.3.0

Member

timowest commented Dec 12, 2011

Released in 2.3.0

@timowest timowest closed this Dec 12, 2011

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment