[hibernate-dev] Patch for HHH-272: Custom SQL for column gets and sets

Steve Ebersole steve at hibernate.org
Thu Sep 3 16:39:31 EDT 2009

1) Personally, I don't like the attribute names sql-get and sql-set.
When I think through trying to describe and explain this feature to
people, the terms "wrap" and "unwrap" keep coming to my head as being
descriptive, relevant and natural.  It was really the "naturalness"
aspect that got me with sql-get and sql-set.  Other terms I could think
of included encode/decodeAny other suggestions? 

2) Can anyone foresee a valid use-case for allowing one of these to be
defined w/o the other?  The only thing I came up with was for immutable
properties.  So something like <column name="xyz" unwrap="decode(xyz)"
insert="false" update="false"/>, which can also be defined using a
formula like <formula>decode(xyz)</formula>.  The reason I ask is that
if they should always be used together then maybe it is better to
enforce that in the DTD and/or binder

3) You renamed the getTemplate method on Selectable to
getGetterTemplate.  Everything in the o.h.mapping package is an SPI that
is used by many other libraries.  We need to be very careful about
changing stuff in here.  I am not sure if folks bind to this particular
method.  But since this is just a cosmetic change, I think it should be

Still not done looking through the whole patch.  Will try to finish up

On Wed, 2009-09-02 at 17:02 -0500, Steve Ebersole wrote:
> Awesome!  This is one of those things I always wanted to get implemented
> but it was always getting pushed down my priority list.  Thanks for
> taking on that work.
> I'll definitely take a look this week.  If you could work it up for
> trunk that would be better.  New features should really not get added to
> maintenance releases.
> On Wed, 2009-09-02 at 17:17 -0400, Rob Hasselbaum wrote:
> > Hi,
> > 
> > I've submitted a patch with unit tests for HHH-272 and I'm interested
> > in feedback. The patch allows users to specify custom SQL get and set
> > expressions for property columns. This can be used to call SQL
> > functions or perform some other kind of database-side conversion
> > without giving up automatic statement generation. You use it like
> > this:
> > 
> > <property name="creditCardNumber">
> >   <column name="credit_card_num" sql-set="encrypt(?)"
> > sql-get="decrypt(credit_card_num)"/>
> > </property>
> > 
> > This is similar to a formula property with two differences. First, the
> > data is backed by a real column, which gets exported with the schema.
> > And second. the data is read-write, not read-only. The sql-get
> > expression gets applied in predicates, order clauses, projections,
> > etc.
> > 
> > The patch should work for all property columns including those in
> > components and composite-elements. I didn't try to get id, key, index,
> > or other kinds of non-property columns to work. It is built on top of
> > the 3.3.2.GA tag, but I can port it to trunk if necessary. I also have
> > a patch nearly ready to expose this functionality in Hibernate
> > Annotations in case the Core patch is accepted. If any commiters could
> > have a look, I'd appreciate it.
> > 
> > Thanks for your time,
> > -Rob Hasselbaum
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
Steve Ebersole <steve at hibernate.org>

More information about the hibernate-dev mailing list