ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brandon Goodin" <brandon.goo...@gmail.com>
Subject Re: Direct-to-Field mappings now implemented.
Date Wed, 14 Feb 2007 17:06:29 GMT
Yes, this is a repost... but now that the point has come up...

To avoid the unpredictability of this functionality couldn't we add some
configure options like:

* a diretoryToMappintEnabled=true/false property on the SQL Map Config. This
would set it globally. False would follow strict bean and (eventually)
constructor setting.
* To bring further clarity we should define the lookup order in our docs.
First a setter is attempted and then a property is attempted ( I would
guess)
* Perhaps you could even go as far as placing a reverseLookup=true/false
field on mappings so that the field is examined before the setter this could
be done in the inline and xml based mappings.

Just some thoughts that may provide our usual implicit/explicit options.
Layout the functionality to act in a common known way and provide the
ability to tweak it when needed.


Brandon


On 2/14/07, Niels Beekman <n.beekman@wis.nl> wrote:
>
> Clinton,
>
> I extracted the property get/set method logic (now in ClassInfo) to a
> separate property access strategy interface and class and created
> another implementation that accesses fields directly.
> However, this starts to look more and more like the classes already in
> the package com.ibatis.sqlmap.engine.accessplan, maybe you have any
> ideas on how to eliminate this duplication; IMO ClassInfo does too much
> work now.
>
> I modified iBATIS to use my implementation directly, but that could
> easily be placed in some configuration property which could control the
> desired behavior:
> - Beanstyle: previous iBATIS behavior
> - Fallback #1: latest iBATIS SVN behavior, first methods then fields
> - Fallback #2: my behavior, first fields then methods
>
> I hope you'll consider adding some configuration for this so I can
> reduce forked custom code :)
>
> Thanks,
>
> Niels
>
> -----Original Message-----
> From: Clinton Begin [mailto:clinton.begin@gmail.com]
> Sent: woensdag 14 februari 2007 15:14
> To: user-java@ibatis.apache.org
> Subject: Re: Direct-to-Field mappings now implemented.
>
> Yes, we decided against a special syntax for fields.
>
> How did you do implement yours?
>
> Cheers,
> Clinton
>
> On 2/14/07, Niels Beekman <n.beekman@wis.nl> wrote:
> > Hi Clinton,
> >
> > I have been using something like this (custom written) for over a
> year,
> > and was happy to see it implemented in iBATIS, just when I was about
> to
> > try the new syntax I saw your commit log:
> >
> > "Changed syntax of field mappings to be exactly the same as property
> > mappings. It now decides to use field mappings only if set/get methods
> > do not exist."
> >
> > Does this mean it can only be used as a fallback? That would be a
> > show-stopper for me, since I use it to prevent issues when loading
> > objects from the database. For example: our setters have validation
> code
> > in place which shouldn't be triggered when loading from the database.
> >
> > Thanks,
> >
> > Niels
> >
> > -----Original Message-----
> > From: Clinton Begin [mailto:clinton.begin@gmail.com]
> > Sent: vrijdag 9 februari 2007 8:45
> > To: dev@ibatis.apache.org; user-java@ibatis.apache.org
> > Subject: Direct-to-Field mappings now implemented.
> >
> > Hi all,
> >
> > I found a few hours tonight to implement direct-to-field mappings.  I
> > don't have any energy left to explain it fully, but it's simple to
> > use, so here's the summary.
> >
> > To implement this, I changed the ClassInfo to accept a new pattern of
> > "property" access.  You can now wrap a field names in round brackets
> > to distinguish them from properties.  So:
> >
> > "id" is a property.
> > "(id)" is a field.
> >
> > These can be mixed with properties like:
> >
> > "account.(address).street"
> >
> > This last point is important and is the primary reason I didn't use a
> > new XML tag -- that would have severely limited the mix-n-match
> > ability of the feature (and it would have been harder to implement).
> >
> > This approach works for reads and writes and for both inline or
> > external parameter maps and result maps.
> >
> > It should be ubiquitous.  Anywhere you used to use property names, you
> > can now use (field) names too.
> >
> > Thoughts?  It's not too late to change the syntax (round brackets) or
> > anything else.
> >
> > I think it's the simplest, most flexible and performant approach.
> >
> > Cheers,
> > Clinton
> >
>

Mime
View raw message