ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Ellis <ellis....@gmail.com>
Subject Re: Scala object support in iBATIS 3
Date Thu, 31 Dec 2009 12:11:58 GMT
2009/12/31 Chris Reeves <chris@ev-soft.net>:
> I would like to add support for scala objects to iBATIS 3 for a
> project I'm working on, and I have a few questions before I dive in
> too deep.

Sounds interesting.
I assume you're referring to the need to call foo_= instead of setFoo.

> This would allow the scala support to be added to the
> project in a contrib module so the main project would have no
> dependencies on the scala libraries, as I will probably use the
> ScalaObject marker interface to create the appropriate wrapper. Of
> course, if no one else is interested in native scala object support,
> this is moot.

Not sure I follow.  Is there any benefit in casting to ScalaObject? I
wonder whether it's possible to reference the ScalaObject interface by
name only (hence, no need to link to it).

Another option (if you do want to link to the scala libraries) might
be to make it an optional dependency.  Currently, iBATIS has build
dependencies on all sorts of logging frameworks, but they're all
optional at runtime.  Could do a similar thing with the scala libs (I
assume you're thinking about writing the integration in Java).

> However, other getter/setter naming strategies that don't conform to
> the javabeans spec could also be plugged in if there was a
> configurable wrapper factory, which probably isn't very useful to most
> java developers, but may be useful for other jvm languages or some
> seriously strange legacy cruft.

On the other hand, even for code with conventional getter/setter
naming, it might be useful for handling different column naming

In the iBATIS app I'm working on, all the database columns have
underscore_names, so I've ended up using column aliasing (SELECT
foo_bar fooBar, ...) for each column.

I never figured out whether there was a better way to do this, but at
the time I was looking for a way to implement exactly the 'pluggable'
naming strategies you describe.


To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
For additional commands, e-mail: user-java-help@ibatis.apache.org

View raw message