Re: [VOTE] Release of DbUtils 1.3 RC4

[Liam Coughlin]

+1

On Mon, Nov 9, 2009 at 6:12 AM, Julien Aymé  wrote:

> +1
>
> Julien
>
> 2009/11/8 Dan Fabulich :
> >
> > This release includes support for Java5 generics and varargs.
> >
> > In RC3 I accidentally added a dependency on Java 1.6 while fixing
> FindBugs
> > errors; in RC4 I fixed that bug.
> >
> > As noted in earlier RCs, I believe 1.3 to be a backwards compatible
> binary,
> > but I'm still only 99% sure of this; clirr reports a bunch of
> compatibility
> > errors that look like nonsense. I did run the compiled 1.2 tests against
> 1.3
> > and it looks OK.
> >
> > +1 from me!
> >
> > --
> >
> > Tag:
> >
> >
> https://svn.apache.org/repos/asf/commons/proper/dbutils/tags/DBUTILS_1_3_RC4/
> >
> > Site:
> >
> > http://people.apache.org/builds/commons/dbutils/1.3/RC4/site/index.html
> >
> > Binaries:
> >
> >
> http://people.apache.org/builds/commons/dbutils/1.3/RC4/staged/commons-dbutils/commons-dbutils/1.3/
> >
> > [ ] +1 release it
> > [ ] +0 go ahead I don't care
> > [ ] -1 no, do not release it because
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: Commons Dbutils: Request feedback for possible patch; handling nested beans.

[Liam Coughlin]

t; propertyForBeanMember.get(property);
> >   String fieldNameCapitalized =
> fieldName.substring(0, 1)
> >   .toUpperCase()
> >   + fieldName.substring(1);
> >   String fieldGetterName = "get" +
> fieldNameCapitalized;
> >   String fieldSetterName = "set" +
> fieldNameCapitalized;
> >   Method fieldGetterMethod = beanClass
> >
> .getDeclaredMethod(fieldGetterName);
> >   Method fieldSetterMethod = null;
> > // we have to go thru all the methods because
> > // PropertyDescriptor doesn't seem to provide a way to retrieve
> > // the fieldClass
> > // i.e. we would have liked to simply do
> > // fieldSetterMethod = beanClass.getDeclaredMethod(fieldSetterName,
>  Bar.class);
> >   Method[] allMethods =
> beanClass.getDeclaredMethods();
> >   for (Method m : allMethods) {
> >   String mname = m.getName();
> >   if (mname.equals(fieldSetterName)) {
> >   fieldSetterMethod = m;
> >   break;
> >   }
> >   }
> >   Field beanField =
> beanClass.getDeclaredField(fieldName);
> >   Class nestedBeanType = beanField.getType();
> >   Object nestedBeanValue =
> fieldGetterMethod.invoke(bean);
> >   // nestedBeanValue is the value in the reference
> >   if (nestedBeanValue == null) {
> >   // create
> >   nestedBeanValue =
> nestedBeanType.newInstance();
> >   // set value to new instance
> >   fieldSetterMethod.invoke(bean,
> nestedBeanValue);
> >   }
> >   System.out.println(" property :" + property
> >   + " target nested Bean: " +
> nestedBeanValue);
> >   Class propType = property.getPropertyType();
> >   Object targetValue = this.processColumn(rs, rs
> >   .findColumn(property.getName()), propType);
> >   if (propType != null && targetValue == null
> >   && propType.isPrimitive()) {
> >   targetValue =
> primitiveDefaults.get(propType);
> >   }
> >   this.callSetter(nestedBeanValue, property,
> targetValue);
> >   } catch (Exception e) {
> >   e.printStackTrace();
> >   throw new SQLException(e.getMessage());
> >   }
> >   }
> >   return bean;
> > }
> >
> >
> > thanks,
> > Anil Philip
> >
> > -Original Message-
> > From: Liam Coughlin [mailto:lscough...@gmail.com]
> > Sent: Wednesday, July 22, 2009 1:26 PM
> > To: Commons Developers List
> > Subject: Re: Commons Dbutils: Request feedback for possible patch;
> handling nested beans.
> >
> > The default BeanHandler is not a full mapping solution and I'm not sure
> you
> > really want it to be -- that's a case where it might be in your best
> > interest to implement a custom Handler.
> >
> > Cheers
> > -L
> >
> > On Wed, Jul 22, 2009 at 12:59 PM, Philip, Anil - Kansas City, MO <
> > anil.phi...@kcc.usda.gov> wrote:
> >
> >>
> >> Here is the example - I had an idea and implemented a possible fix that
> >> works. I would like to know before I submit a patch, whether it really
> is a
> >> solution or if there is a better way. In short, can I get feedback here?
> >> 
> >> Problem:
> >> Some of our beans contain object references to other beans. Those nested
> >> beans may have properties that are intended to be filled in by one or
> more
> >> fields from a query. However, since it is not on the surface, Dbutils
> cannot
> >> find where the property is and so the nested property remains unfilled.
> >>
> >> Example:
> >> Consider a table Moods to track our demeanor while we engage in an
> >> activity. So it has two columns; face (demeanor) and activity.
> >>
> >> FaceActivity

Re: Commons Dbutils: Request feedback for possible patch; handling nested beans.

[Liam Coughlin]

The default BeanHandler is not a full mapping solution and I'm not sure you
really want it to be -- that's a case where it might be in your best
interest to implement a custom Handler.

Cheers
-L

On Wed, Jul 22, 2009 at 12:59 PM, Philip, Anil - Kansas City, MO <
anil.phi...@kcc.usda.gov> wrote:

>
> Here is the example - I had an idea and implemented a possible fix that
> works. I would like to know before I submit a patch, whether it really is a
> solution or if there is a better way. In short, can I get feedback here?
> 
> Problem:
> Some of our beans contain object references to other beans. Those nested
> beans may have properties that are intended to be filled in by one or more
> fields from a query. However, since it is not on the surface, Dbutils cannot
> find where the property is and so the nested property remains unfilled.
>
> Example:
> Consider a table Moods to track our demeanor while we engage in an
> activity. So it has two columns; face (demeanor) and activity.
>
> FaceActivity
> -   
> huffing Jog
> smile   Work
> engrossed   movie
> sad Cry
> distant distracted
> bored   waiting
>
> Bean Foo contains an object reference to an instance - a bean- of class
> Bar. Foo contains data field or property 'face', and Bar contains the
> property 'activity', that we want to fill from this query:
> "select face, activity from Mood"
>
> public class Foo {
>private String face;
>private Bar bar;
>public String getFace() {return face;}
>public void setFace(String face) {this.face = face;}
>public void setBar(Bar bar) {this.bar = bar;}
>public Bar getBar() {return bar;}
> }
> public class Bar {
>private String activity;
>public String getActivity() {return activity;}
>public void setActivity(String activity) {this.activity = activity;}
> }
>
> Old way:
> QueryRunner runner = new QueryRunner();
> BeanHandler bh = new BeanHandler(Foo.class);
> Foo foo = (Foo) runner.query(connection,
>"select face, activity from Mood", bh);
>
> Result:
> Foo.bar is null and its fields are unpopulated.
>
> thanks,
> Anil Philip
>
> -Original Message-
> From: Dan Fabulich [mailto:d...@fabulich.com]
> Sent: Tuesday, July 21, 2009 7:13 PM
> To: Commons Developers List
> Subject: Re: Commons Dbutils: Request feedback for possible patch; handling
> nested beans.
>
> Philip, Anil - Kansas City, MO wrote:
>
> > We use dbutils in my team and found a problem when a bean has nested
> object references.
> > The properties in the nested bean are obviously not filled in.
>
> File a bug with an example?  I'm not sure I quite understand your
> scenario.
>
> http://issues.apache.org/jira/browse/DBUTILS
> (You need to login to file a bug.)
>
> -Dan
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

[Commons-JCI]

[Liam Coughlin]

Is this project still active?  there's a 1.1 release sort of sitting dormant
since ~2007...

Re: [dbutils] Version number for next release

[Liam Coughlin]

You're right on the money with that one.

I'd like to have some brainstorming conversations and what not along the the
way to 2.0 -- I don't think a major version bump is necessary in a library
like this until you do break compatibility.

Cheers,
-L

On Fri, May 1, 2009 at 11:43 AM, Dan Fabulich  wrote:

>
> With the release of DbUtils 1.2, we're actually basically already ready to
> do another release of DbUtils, this time with enhancements specific to Java
> 5 (generics + varargs).
>
> The new Java 5 API is 100% compatible at runtime with the API of DbUtils
> 1.2 (or, at least, I tried to do so, I'll be sure to use API comparison
> tools prior to release and fix any bugs I find).
>
> I'd like to call this new release DbUtils 1.3.  I can imagine someone
> arguing that it should be 2.0, but I don't think so; in DbUtils 1.2 we just
> raised the required JRE version from 1.3 to 1.4 and I think that's fine.
>
> The difference between Java 1.4 and 1.5 is much bigger than the difference
> between 1.3 and 1.4, but not so great, I think, that a major version bump is
> required.
>
> If nobody objects, I'll start preparing for a DbUtils 1.3 release in about
> 72 hours.
>
> -Dan
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [VOTE] Release of DbUtils 1.2 RC3

[Liam Coughlin]

+1 i suppose.

Same issue occurs with oracle 11g drivers as well, but you're correct, it's
not a regression -- I hadn't really noticed it because bizzarely, i'm using
the data direct drivers and they don't show the issue.

The issue's been raised on oracles forums a couple of times.

My kingdom for a typed null.

-shrug-


On Mon, Apr 13, 2009 at 2:20 AM, Dan Fabulich  wrote:

> Took me a few weeks, but I finally got around to installing a free instance
> of Oracle (Express Edition 10.2) and testing the null handling code we
> introduced in DbUtils 1.2 (DBUTILS-31).
>
> Sure enough, there's a bug, DBUTILS-55, but I don't think it's very
> important, since it's not a regression; it was there in DbUtils 1.1 and
> nobody appears to have noticed or cared.  :-)  Also, I have no idea how we
> could possibly fix it, since Oracle's JDBC driver doesn't support
> ParameterMetaData.getParameterType.
>
> With that done, and having tested successfully with Apache Derby, I'm now
> prepared to give RC3 my +1.  I believe we also already have a +1 from Joerg
> Schaible, so we still need two more binding +1s to release.
>
> -Dan
>
>
> Dan Fabulich wrote:
>
>
>> My third attempt at releasing a commons project; please test rigorously!
>>
>> RC3 includes an API change to QueryRunner to guarantee thread-safety.
>> (DBUTILS-52)
>>
>> NOTE: No one has yet explicitly said on-list that they have tested DbUtils
>> 1.2 with a real database.  We should not release it until somebody tries it
>> out with a real live Oracle database, as described below.
>>
>> Compatibility warnings:
>>
>> * API change in QueryRunner: the setDataSource method was removed in order
>> to fix a thread-safety bug (DBUTILS-52)
>> * We upgraded the JVM dependency from JDK 1.3 to JDK 1.4 (DBUTILS-31)
>> * Users who may have extended BeanListHandler.handleRow will find that
>> this method no longer exists (is no longer called) in DbUtils 1.2
>> (DBUTILS-37)
>> * Users who may have extended KeyedHandler will find that its protected
>> members are now final (to guarantee thread safety). (DBUTILS-51)
>>
>> PLEASE TEST THIS RELEASE WITH A REAL DATABASE!
>>
>> Although this project has reasonable unit tests, it has no integration
>> tests with any actual databases; it is quite possible that the fix for
>> DBUTILS-31 has broken something on Oracle, MS SQL Server, Derby, or your
>> favorite database.
>>
>> To verify DBUTILS-31, use QueryRunner to put a null value in a field, e.g.
>> with QueryRunner.update.  Ideally it would be good to verify putting nulls
>> in fields of various types: char, varchar, int, boolean, date, etc.
>>
>> --
>>
>> Tag:
>>
>> https://svn.apache.org/repos/asf/commons/proper/dbutils/tags/DBUTILS_1_2
>>
>> Site:
>>
>> http://people.apache.org/builds/commons/dbutils/1.2/RC3/site/index.html
>>
>> Binaries:
>>
>>
>> http://people.apache.org/builds/commons/dbutils/1.2/RC3/staged/commons-dbutils/commons-dbutils/1.2/
>>
>> [ ] +1 release it
>> [ ] +0 go ahead I don't care
>> [ ] -1 no, do not release it because
>>
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: RES: RES: RES: Possible incubation?

[Liam Coughlin]

:s/Unchecked/checked/

i suck.

On Fri, Apr 10, 2009 at 11:00 AM, Liam Coughlin wrote:

> The real problem is that Unchecked exceptions still exist, and are way over
> used.
>
> -shrug-
>
>
>
> On Fri, Apr 10, 2009 at 8:28 AM, Andre Dantas Rocha <
> andre.dantas.ro...@uol.com.br> wrote:
>
>> I totally agree with you about HandleUtil.handle(); this is a point that I
>> want to avoid either. However, the current weaving implementation isn't so
>> flexible and today this is the only way it works.
>>
>> As I wrote in my last emails, it is still necessary to work on
>> Mojo/weaving
>> to solve this kind of problem.
>>
>> Andre
>>
>> -Mensagem original-
>> De: Gaurav Arora [mailto:gauravar...@codercorp.com]
>> Enviada em: sexta-feira, 10 de abril de 2009 09:00
>> Para: Commons Developers List
>> Assunto: Re: RES: RES: RES: Possible incubation?
>>
>> Apologies for the late reply.
>>
>> > But... and if does the user specify an handler that are not supposed to
>> > handle that code? Isn't better to throw an exception instead of
>> returning
>> > the original one?
>>
>> Hmm, when I think about it, I think it is better to throw the exception
>> than return it, returning would again cause extra code in the caller.
>>
>> I just want to touch up on a point you mentioned in your other mail about
>> HandlerUtil.handle(). I personally would love to avoid such a call at all.
>> I think the entire framework should be as transparent as possible to avoid
>> unnecessary code. The annotation already provides metadata for a developer
>> to refer too so there isn't a need for an explicit call.
>>
>> Gaurav
>>
>> > I agree with you in some points. Maybe it is better to return inside
>> > exceptions to the caller instead of catch them locally.
>> >
>> > The problem, for me, remains in this part: "see if we have a method to
>> > handle such an exception by checking if a method
>> > handleIllegalArgumentException exists"
>> >
>> > I believe that implement an handleIllegalArgumentException() method it's
>> > not
>> > the best solution for the problem. Maybe the best strategy is to
>> overload
>> > handle() method for handling exceptions of handler's responsibility. For
>> > example, Instead of handleIllegalArgumentException(), codify a
>> > handle(IllegalArgumentException e):
>> >
>> > public class MyHandler implements handler {
>> >public Throwable handle(IllegalArgumentException e, ...) {
>> >  // specific code
>> >}
>> >
>> >public Throwable handle(Throwable t, ...) {
>> >   return t;
>> >}
>> > }
>> >
>> > But... and if does the user specify an handler that are not supposed to
>> > handle that code? Isn't better to throw an exception instead of
>> returning
>> > the original one?
>> >
>> > Andre
>> >
>> >
>> > -Mensagem original-
>> > De: Gaurav Arora [mailto:gauravar...@codercorp.com]
>> > Enviada em: quarta-feira, 8 de abril de 2009 12:37
>> > Para: Commons Developers List
>> > Assunto: Re: RES: RES: Possible incubation?
>> >
>> > I agree with you that there is no elegant way to say what can and cannot
>> > be handled by the handler so what I suggest is let the handler decide
>> what
>> > it can and cannot handle. Looking at the handler should give one a clear
>> > picture of what its equipped to handle.
>> >
>> > Here's what I mean with an example:
>> >
>> > @ExceptionHandler(MyHandler.class)
>> > public void foo() {
>> > try {
>> > doSomething();
>> > } catch (Exception ex) {
>> > handler.handle(ex);
>> > }
>> > }
>> >
>> > Assume the above method throws an IllegalArgumentException.
>> >
>> > In our handler:
>> > public Throwable handle(Exception e) {
>> > // get the type of exception
>> > // see if we have a method to handle such an exception by checking
>> if
>> > a method handleIllegalArgumentException exists
>> > // if we don't simply return the exception back
>> > }
>> >
>> > This way there is no need to explicitly define what exceptions can and
>> > cannot be handled. What is not handled is simply thrown back to the
>> > caller. But what i

Re: RES: RES: RES: Possible incubation?

[Liam Coughlin]

The real problem is that Unchecked exceptions still exist, and are way over
used.

-shrug-


On Fri, Apr 10, 2009 at 8:28 AM, Andre Dantas Rocha <
andre.dantas.ro...@uol.com.br> wrote:

> I totally agree with you about HandleUtil.handle(); this is a point that I
> want to avoid either. However, the current weaving implementation isn't so
> flexible and today this is the only way it works.
>
> As I wrote in my last emails, it is still necessary to work on Mojo/weaving
> to solve this kind of problem.
>
> Andre
>
> -Mensagem original-
> De: Gaurav Arora [mailto:gauravar...@codercorp.com]
> Enviada em: sexta-feira, 10 de abril de 2009 09:00
> Para: Commons Developers List
> Assunto: Re: RES: RES: RES: Possible incubation?
>
> Apologies for the late reply.
>
> > But... and if does the user specify an handler that are not supposed to
> > handle that code? Isn't better to throw an exception instead of returning
> > the original one?
>
> Hmm, when I think about it, I think it is better to throw the exception
> than return it, returning would again cause extra code in the caller.
>
> I just want to touch up on a point you mentioned in your other mail about
> HandlerUtil.handle(). I personally would love to avoid such a call at all.
> I think the entire framework should be as transparent as possible to avoid
> unnecessary code. The annotation already provides metadata for a developer
> to refer too so there isn't a need for an explicit call.
>
> Gaurav
>
> > I agree with you in some points. Maybe it is better to return inside
> > exceptions to the caller instead of catch them locally.
> >
> > The problem, for me, remains in this part: "see if we have a method to
> > handle such an exception by checking if a method
> > handleIllegalArgumentException exists"
> >
> > I believe that implement an handleIllegalArgumentException() method it's
> > not
> > the best solution for the problem. Maybe the best strategy is to overload
> > handle() method for handling exceptions of handler's responsibility. For
> > example, Instead of handleIllegalArgumentException(), codify a
> > handle(IllegalArgumentException e):
> >
> > public class MyHandler implements handler {
> >public Throwable handle(IllegalArgumentException e, ...) {
> >  // specific code
> >}
> >
> >public Throwable handle(Throwable t, ...) {
> >   return t;
> >}
> > }
> >
> > But... and if does the user specify an handler that are not supposed to
> > handle that code? Isn't better to throw an exception instead of returning
> > the original one?
> >
> > Andre
> >
> >
> > -Mensagem original-
> > De: Gaurav Arora [mailto:gauravar...@codercorp.com]
> > Enviada em: quarta-feira, 8 de abril de 2009 12:37
> > Para: Commons Developers List
> > Assunto: Re: RES: RES: Possible incubation?
> >
> > I agree with you that there is no elegant way to say what can and cannot
> > be handled by the handler so what I suggest is let the handler decide
> what
> > it can and cannot handle. Looking at the handler should give one a clear
> > picture of what its equipped to handle.
> >
> > Here's what I mean with an example:
> >
> > @ExceptionHandler(MyHandler.class)
> > public void foo() {
> > try {
> > doSomething();
> > } catch (Exception ex) {
> > handler.handle(ex);
> > }
> > }
> >
> > Assume the above method throws an IllegalArgumentException.
> >
> > In our handler:
> > public Throwable handle(Exception e) {
> > // get the type of exception
> > // see if we have a method to handle such an exception by checking if
> > a method handleIllegalArgumentException exists
> > // if we don't simply return the exception back
> > }
> >
> > This way there is no need to explicitly define what exceptions can and
> > cannot be handled. What is not handled is simply thrown back to the
> > caller. But what it does is provides a very clean caller in the sense
> that
> > it has no actual exception handling code, just a single catchAll.
> >
> > I am not sure on what exceptions should be handled by the handle method
> > itself. Asking the handler to handle all it's own exceptions, in a way,
> > again asks you to duplicate the code, which is what Jeha is trying to
> > remove. Otherwise, you'll need to define exception handlers for the
> > handlers themselves which in my view can get tricky real fast.
> >
> > I don't think that the option of rethrowing should rest with the caller.
> > What the caller is saying is that the handler will handle all it's
> > exceptions and it itself knows nothing about what is going on. Asking the
> > caller to handle rethrows sort of splits the responsibility between the
> > two which again, is something that can get tricky.
> >
> > Gaurav
> >
> >
> >> Hi Gurav,
> >>
> >> The weaving could be accomplished statically using ASM, BCEL, Javassist
> >> or
> >> any similar tool. In my opinion, a bytecode library must be used only
> >> during
> >> compilation process; it's better (and cleaner) if the program

[Commons-JCI]

[Liam Coughlin]

Is this project dormant?  Nothing much seems to have happened with it for a
minute

Re: M2 settings.xml

[Liam Coughlin]

oops?

On Wed, Mar 25, 2009 at 9:51 AM, Siegfried Goeschl <
siegfried.goes...@it20one.at> wrote:

> 
>
>  
>
>  apache.releases
>  sgoeschl
>  664
>  775
>
>
>  apache.website
>  sgoeschl
>  664
>  775
>
>
>  apache.snapshots
>  sgoeschl
>  664
>  775
>
>
>  website
>  sgoeschl
>
>
>  fulcrum.website
>  sgoeschl
>
>
>  sgoeschl.website
>  sgoeschl
>
>  
>
> 
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [VOTE] Release of DbUtils 1.2 RC2

[Liam Coughlin]

I'd suggest marking it volatile or making it an immutable property.  the
overhead incurred from enforcing thread safety i think is a bit much for the
specific purpose of the QueryRunner -- in all the instances that you
mentioned -- it's the datasource that should be dispatched to threads not
the queryRunner anyways.

On Sun, Mar 15, 2009 at 2:52 PM, sebb  wrote:

> On 15/03/2009, Dan Fabulich  wrote:
> > sebb wrote:
> >
> >
> > > OK, I'd not noticed that the class was usable without the DataSource.
> > >
> > > Of course the alternative is to document the class as thread-unsafe...
> > >
> >
> >  I would guess that the reason we've never seen a bug filed on this issue
> is
> > that nobody uses setDataSource after the class is created.  For these
> users,
> > QueryRunner is thread-safe.  I think just formalizing that state is best.
>
> If you mean nobody uses setDataSource at all, then I agree that cannot
> affect thread-safety.
>
> However, if anyone uses setDataSource (which has to be after creation)
> and passes the instance to another thread, then the receiving thread
> may not see the updated value for the ds variable, i.e. it would not
> be thread-safe.
>
> > >
> > > >  I would not attempt to synchronize this class, just leave it unsafe
> and
> > let
> > > > users synchronize.  We should document more explicitly that (unlike
> some
> > > > other classes in DbUtils) it's unsafe.
> > > >
> > >
> > > I'm not sure that the class can be made thread-safe externally.
> > >
> > > It's easy enough to override the setters with synchronized versions,
> > > but the getters need to be synchronized as well to ensure that the
> > > data is published correctly. However the class stores the
> > > unsynchronized getters in the Map. So it would be necessary to
> > > override invoke() as well. If this is done, then the whole class has
> > > been overridden - one might as well say it has been rewritten.
> > >
> >
> >  I didn't mean that users would synchronize externally by
> > extending/overriding, but just by synchronizing access to an instance
> > member, or just not sharing them across threads.  *shrug*
>
> For a mutable instance field to be thread-safe, both writes and reads
> need to be synchronized (or volatile). It's not enough to synch. just
> the writes, and readers and writers must all use the same lock.
>
> >
> >  -Dan
> >
> > -
> >  To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >  For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [VOTE] Release of DbUtils 1.2 RC3

[Liam Coughlin]

Unless something has changed, the current test cases do include hsqldb based
tests.

The specific issue is that some of the changes in the proposed 1.2 have a
specific impact on specific databases ( notably, oracle ) -- so it would be
extremely useful if someone who has some access to some oracle instances
could run some basic tests.

Cheers
-L

On Mon, Mar 16, 2009 at 3:24 PM, James Carman wrote:

> Why can't our test suite include some hsqldb-based tests?  We do that at
> work to test our hibernate queries and stuff.  Each test case class gets
> their own in-memory database.  Performance isn't an issue
>
> On Mar 15, 2009 3:10 PM, "Dan Fabulich"  wrote:
>
>
> My third attempt at releasing a commons project; please test rigorously!
>
> RC3 includes an API change to QueryRunner to guarantee thread-safety.
> (DBUTILS-52)
>
> NOTE: No one has yet explicitly said on-list that they have tested DbUtils
> 1.2 with a real database.  We should not release it until somebody tries it
> out with a real live Oracle database, as described below.
>
> Compatibility warnings:
>
> * API change in QueryRunner: the setDataSource method was removed in order
> to fix a thread-safety bug (DBUTILS-52)
> * We upgraded the JVM dependency from JDK 1.3 to JDK 1.4 (DBUTILS-31)
> * Users who may have extended BeanListHandler.handleRow will find that this
> method no longer exists (is no longer called) in DbUtils 1.2 (DBUTILS-37)
> * Users who may have extended KeyedHandler will find that its protected
> members are now final (to guarantee thread safety). (DBUTILS-51)
>
> PLEASE TEST THIS RELEASE WITH A REAL DATABASE!
>
> Although this project has reasonable unit tests, it has no integration
> tests
> with any actual databases; it is quite possible that the fix for DBUTILS-31
> has broken something on Oracle, MS SQL Server, Derby, or your favorite
> database.
>
> To verify DBUTILS-31, use QueryRunner to put a null value in a field, e.g.
> with QueryRunner.update.  Ideally it would be good to verify putting nulls
> in fields of various types: char, varchar, int, boolean, date, etc.
>
> --
>
> Tag:
>
> https://svn.apache.org/repos/asf/commons/proper/dbutils/tags/DBUTILS_1_2
>
> Site:
>
> http://people.apache.org/builds/commons/dbutils/1.2/RC3/site/index.html
>
> Binaries:
>
>
> http://people.apache.org/builds/commons/dbutils/1.2/RC3/staged/commons-dbutils/commons-dbutils/1.2/
>
> [ ] +1 release it
> [ ] +0 go ahead I don't care
> [ ] -1 no, do not release it because
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

Re: [DBUTILS] Version numbering

[Liam Coughlin]

That makes a little more sense then how I read the Stephen originally, and
yes you're probably right -- though I don't think you're going to be able to
get much varargs in without wrecking binary anyway since a lot of the
parameter ordering doesn't lend itself to it.

I just don't feel that a 1.3 java 5 "Now with Special Sauce but  the Same
Old Hamburger" release would be all that useful in the long run, but i could
be completely wrong.

Cheers,
-L



n...@fabulich.com > wrote:
> > "NEEDS" is a little strong  I think there's room in the world for a
> > backwards-compatible dbutils 1.3 with generics and varargs followed
> shortly
> > afterward by a more thoroughly re-worked dbutils 2.0.
>
>

Re: [DBUTILS] Version numbering

[Liam Coughlin]

the code NEEDS to change though, and not in a backwards compatible way.  Do
whatever is appropriate with version numbers to indicate that non-binary
compatible changes are coming.

Cheers,
-L

On Sun, Mar 8, 2009 at 6:04 AM, Stephen Colebourne <
scolebou...@btopenworld.com> wrote:

> Dan Fabulich wrote:
>
>> Henri Yandell wrote:
>>
>>  The Java5 version is more up for debate. If the API is no longer
>>> compatible, then we start to lean to 2.0. Especially as calling it 2.0
>>> allows for more of an overhaul of API.
>>>
>>
>> The the API in the "java5" branch is backward compatible; the generics and
>> varargs are erased at compile time.  Of course, the code has to be compiled
>> with target=1.5, but on a Java 1.5 VM you could swap it in and not notice
>> the difference.
>>
>
> Check javap method signatures, or use clirr.
>
>
> Stephen
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [dbutils] bugfixing/java5 branches ready for merge

[Liam Coughlin]

DBUTILS-49QueryRunner - fillStatement method does not work for
PostgreSQL database drivers
I'm pretty sure this is addressed with the fill change to use the
parametermetadata.

DBUTILS-48 Maintaining a parallel Java 1.5 version of
DButils
You folks are covering this with the different branch configs post buf fix.

DBUTILS-47 Add a StatementFiller to be able to provide a Bean for
updates, instead of bean
values.
I'm pretty sure this is outside the scope of dbutils, and would be covered
by things users of the library add
to it's extensible framework.

DBUTILS-43 an helper set of classes for JDBC processing with prepared
statement 
This is not trivial -- tackle it now, or tackle it later?

DBUTILS-30 [dbutils] New ResultSetHandler -
ObjectHandler
I'm pretty sure this is outside the scope of dbutils, and would be covered
by things users of the library add
to it's extensible framework.

DBUTILS-28 [dbutils] Stored Procedure Runner and Bean Reuse Handler code
submission 
This is sort of a weird double issue that rolls up DBUTILS-43 and
DBUTILS-30.

I think you probably want to defer any work with stored procedures for a
little while because there's just more interesting and important things to
work on.

In short -- you should probably just close them or mark them inactive.


On Wed, Feb 25, 2009 at 5:07 AM, Henri Yandell  wrote:

> On Tue, Feb 24, 2009 at 9:55 AM, Dan Fabulich  wrote:
> > Henri Yandell wrote:
> >
> >> 742870 - ?? - Lacking Unit Tests, not liking the catch Exception.
> >> RuntimeException throwing needs String arg. Generally not trusting the
> >> Java API here to work beautifully and wanting to have covered a bunch
> >> of use cases.
> >
> > Thanks for reviewing!
> >
> > I tweaked exception handling and added unit tests in bugfixing branch
> > revision 747449.  As I wrote the unit tests I manuallly looked at the
> > exception stacktraces and verified that they provided useful error
> messages
> > to the user. http://svn.apache.org/viewvc?view=rev&revision=747449
> >
> > I also merged those changes to java5 branch revision 747452.
> >
> >> So apart from the one commit, I'm +1 on the changes on the bugfixes
> >> branch.
> >
> > In that case, I think we're ready to contemplate executing the plan I'd
> > identified earlier:
> >
> >>> If I were a commons/dbutils committer right now, I think I'd probably
> do
> >>> these things (all of which require committer karma):
> >>>
> >>> 1) Merge "bugfixing" back to trunk
> >>> 2) Close out all of the bugs I fixed
> >>> 3) Stage/vote on a dbutils-1.2 release based on bugfixing/trunk
> >>> 4) Make a dbutils/1.x branch
> >>> 5) Merge "java5" back to trunk
> >>> 6) Stage/vote on a dbutils-2.0 release based on java5/trunk
> >
> > How do we want to begin work on this?  Henri, do you want to these steps?
> > Alternately, I can do them myself if I get the karma to do so...?
>
> I've gone ahead with the merge and bug closing.
>
> Any thoughts on the remaining 6 open issues in JIRA?
>
> Hen
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [dbutils] bugfixing/java5 branches ready for merge

[Liam Coughlin]

I vote for karma.

On Tue, Feb 24, 2009 at 12:55 PM, Dan Fabulich  wrote:

> Henri Yandell wrote:
>
>  742870 - ?? - Lacking Unit Tests, not liking the catch Exception.
>> RuntimeException throwing needs String arg. Generally not trusting the
>> Java API here to work beautifully and wanting to have covered a bunch
>> of use cases.
>>
>
> Thanks for reviewing!
>
> I tweaked exception handling and added unit tests in bugfixing branch
> revision 747449.  As I wrote the unit tests I manuallly looked at the
> exception stacktraces and verified that they provided useful error messages
> to the user. http://svn.apache.org/viewvc?view=rev&revision=747449
>
> I also merged those changes to java5 branch revision 747452.
>
>  So apart from the one commit, I'm +1 on the changes on the bugfixes
>> branch.
>>
>
> In that case, I think we're ready to contemplate executing the plan I'd
> identified earlier:
>
>  If I were a commons/dbutils committer right now, I think I'd probably do
>>> these things (all of which require committer karma):
>>>
>>> 1) Merge "bugfixing" back to trunk
>>> 2) Close out all of the bugs I fixed
>>> 3) Stage/vote on a dbutils-1.2 release based on bugfixing/trunk
>>> 4) Make a dbutils/1.x branch
>>> 5) Merge "java5" back to trunk
>>> 6) Stage/vote on a dbutils-2.0 release based on java5/trunk
>>>
>>
> How do we want to begin work on this?  Henri, do you want to these steps?
> Alternately, I can do them myself if I get the karma to do so...?
>
>
> -Dan
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [beanutils] [dbutils] Interfaces as beans, for databases

[Liam Coughlin]

Yes and Yes!  There is absolutely a lot of potential there -- it's also one
of the reasons I'd really like to see RowHandler become a first class part
of the dbutils library -- ProxyGeneratingRowHandlers could do all sorts of
interesting things.



On Tue, Feb 10, 2009 at 5:28 PM, Dan Fabulich  wrote:

>
> Have you seen ActiveObjects?  It's an incubating ORM layer over at
> dev.java.net; it's got some neat stuff in it.
>
> https://activeobjects.dev.java.net/basic-concepts.html
>
> I'm especially drawn to the idea that a bean could be defined as an
> interface, rather than as a concrete implementation.  It saves me from
> having to actually define the implementation of getters and setters, while
> still preserving type-safety (and auto-completion in my IDE).
>
>  interface Employee {
>public String getName();
>public void setName(String name);
>  }
>
> It's easy to use java.lang.reflect.Proxy to automatically generate simple
> implementations for bean-like interfaces.  The InvocationHandler could just
> keep a DynaBean internally that maps properties to values; when a getter is
> called, we'd just call an appropriate getter on the DynaBean; when a setter
> is called, we'd just call an appropriate setter on the DynaBean.
>
>  Employee e = instantiateBeanInterface(Employee.class);
>
> The result would be something like a type-safe DynaBean, which intrigues
> me.
>
> We could go even further.  Perhaps if the interface bean (IBean?)
> implemented other tagging interfaces, we could add in additional
> functionality.
>
> For example, BeanUtils could define an interface like this:
>
>  interface DirtyManagedBean {
>public PropertyDescriptor[] dirtyProperties();
>public boolean isDirty(String propertyName);
>public void clean(String propertyName);
>public void cleanAll();
>  }
>
> Then, I could make my Employee interface implement DirtyManaged, and have
> the automatically generated bean keep track of which properties were dirty
> (had been modified) and which were clean.
>
> We could also have an interface like this:
>
>  interface SupportsPropertyChange {
>public java.beans.PropertyChangeSupport propertyChangeSupport();
>  }
>
> If my Employee implemented SupportsPropertyChange, I could retrieve its
> associated PropertyChangeSupport object and attach change listeners; we'd
> guarantee that the generated bean would fire change events via the support
> object.
>
> FOR DATABASES
>
> Specifically, I'm imagining IBeans would be helpful in the world of SQL
> databases, outside of any ORM layer.
>
> 1) You could automatically INSERT/UPDATE a DirtyManaged bean, adding only
> explicitly dirty columns to the SQL statement.
>
> 2) In general, an IBean could wrap around a PreparedStatement:
>
>  PreparedStatement ps = prepareStatement();
>  Employee e = proxyPreparedStatement(Employee.class, ps, columnList);
>  employee.setFirstName("Dan");
>  employee.setLastName("Fabulich");
>  ps.addBatch();
>  employee.setFirstName("Somebody");
>  employee.setLastName("Else");
>  ps.addBatch();
>  ps.executeBatch();
>
> 3) An IBean could wrap around a ResultSet; when you call .next() on the
> result set, the IBeans getters/setters could return the new values,
> eliminating the need to create N objects for N rows.
>
>  Employee employee = proxyResultSet(Employee.class, resultSet);
>  while (resultSet.next()) {
>System.out.println("Name: " + employee.getName());
>System.out.println("Address: " + employee.getAddress());
>  }
>
> 3) If you're doing a join, you could define a new bean that wrapped around
> the joined query via multiple inheritance.
>
>  interface EmployeeAddressQuery implements Employee, Address;
>
>  Statement s = c.createStatement("SELECT * from employees, addresses");
>  resultSet = s.executeQuery();
>  Employee employee = proxyResultSet(Employee.class, resultSet);
>  while (resultSet.next()) {
>System.out.println("Name: " + employee.getName());
>System.out.println("Street Name: " + employee.getStreet());
>  }
>
> Thoughts?
>
> -Dan
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [dbutils] Questions about a few of bugs

[Liam Coughlin]

snip

>
> Ah, but the whole point of this enhancement is that it's unperformant to
> use RowProcessor#toBean on each row; it's much faster to call
> RowProcessor#toBeanList once.  So there's no such thing as an
> OptimizedBeanRowHandler; the optimization is to not use a RowHandler!
>
/snip

I'd push back in the complete opposite direction.  You should _always_ use a
rowhandler and the extra fuctions on row handler should all be collapsed to
a single handleRow function -- ditch toBean and toList etc. all together.

ListHandler = new ArrayListHandler( new
BeanRowHandler() )

and the new theoretical BeanRowHandler would only create the index/property
map once per handled resultset ( the real source of the performance issue in
the first place ).

it's a little verbose on the generics but the guts of processing stream
would be significantly simpler ( and thus -- faster ).

Addidtionally you could have a dbutils extra package wich could have
something like a CglibBeanRowHandler or what have you that could generate
and cache classes to execute resulset->bean mappings.




>
>  3) CaseInsensitiveMap
>>> http://issues.apache.org/jira/browse/DBUTILS-34
>>>
>>> Two distinct users claim to want CIM to return the keys in their ORIGINAL
>>> case (i.e. not lowercased).  Why would anyone need this?  I don't get it.
>>>
>>>
>>>  Given the amount of reflection and property referencing that occurs in
>> java
>> apps these days, i can think of a million reasons why a CIM should return
>> the keys in original case.  There shouldn't be any particular performance
>> implication here, just a little bit of extra memory and housekeeping.
>>
>
> Well, here's my thinking:
> 1) We don't provide a public CaseInsensitiveMap in our API.  The CIM is a
> purely private object used in the guts of BasicRowProcessor.
>
> This is why I don't understand the point of the bug...  Why would anyone
> care how this internal object is implemented, so long as BasicRowProcessor
> works?
>

Well the problem is that BasicRowProcessor.toMap returns a CIM.  -- so if
you use the ListMapHandler or any of the other map result functions you get
a CIM back.  This is useful because developers can then interact with the
result map without worring about column casing from the database -- except
where they care about column casing with the database sense?
.entrySet() and .keySet() should of returned Strings in original case in the
first place -- shrug.


>
> 2) Extra housekeeping = slower performance
>

True, balancing act.


>
> 3) The biggest risk here is accidentally introducing thread-safety
> problems.  The patch applied to DBUTILS-34 is not thread-safe (I think?)
> because it keeps two internal data structures (the "real" map and the
> "lowerCaseMap") that can fall out-of-sync, corrupting the map.
>

I haven't looked at the patch itself, but in the laziest case, the
granularity where the race condition could exist -- the race condition still
exists by itself since CIM extends HashMap rather then hashtable  and so
isn't threadsafe per se, and CIM is never wrapped in a failfast wrapper and
( obviously ) doesn't extent ConcurrentHashMap.

Again -- balancing act -- simple API vs eeking out a couple of small points
of performance.

Re: [dbutils] Questions about a few of bugs

[Liam Coughlin]

On Tue, Feb 10, 2009 at 2:32 AM, Dan Fabulich  wrote:

> 1) OptimalBeanListHandler
>
> http://issues.apache.org/jira/browse/DBUTILS-37
> This bug provides a patch that considerably improves the performance of
> BeanListHandler.
>
> However, Julien correctly points out that:
>
>> With the change I propose, the BeanListHandler#handleRow(ResultSet) method
>> is never called anymore. So, any subclass of BeanListHandler which would
>> override this method would not work properly anymore.
>>
>
> Julien's patch creates a separate "OptimalBeanListHandler" ... but that
> really shouldn't be necessary, right?
>
> We should be able to just replace the existing BLH with this fast one
> without worrying about users who may have extended BLH#handleRow, I'd
> think... At the very least I think nobody should use the old slow one by
> accident.
>

Ideally, these classes should be split up more.  There shouldn't really be a
BeanListHandler, just a ListHandler which takes a RowHandler on
construction, and then you can just use the appropriate BeanRowHandler or
OptimizedBeanRowHandler or some other custom row handler to map how you like
which would resolve the whole issue.

Yes, this would be a fairly drastic API change -- one that shold be looked
at pretty seriously for java 5 ports of dbutils.



>
> 2) Inflate existing object
> http://issues.apache.org/jira/browse/DBUTILS-28
>
> I'm a little skeptical of the patch for this bug.  Is this issue important?
>  (It has 0 votes and 0 watchers, so I think not.)
>

Bean reuse handler is a little odd -- but again it comes back to splitting
out a row handler.  The simplest "real"  use case is in mapping database
generated primary keys back into objects for insert statements.

Stored procedure handling is an entirely different issue, and one of the few
places where database specific handlers will probably be needed which is why
it's been avoided so far i think.


> 3) CaseInsensitiveMap
> http://issues.apache.org/jira/browse/DBUTILS-34
>
> Two distinct users claim to want CIM to return the keys in their ORIGINAL
> case (i.e. not lowercased).  Why would anyone need this?  I don't get it.
>
>
Given the amount of reflection and property referencing that occurs in java
apps these days, i can think of a million reasons why a CIM should return
the keys in original case.  There shouldn't be any particular performance
implication here, just a little bit of extra memory and housekeeping.

Cheers,
-L

Re: [dbutils] QueryRunner.fillStatement and the null problem (long)

[Liam Coughlin]

snip

>
>int sqlType = Types.VARCHAR;
>if (!pmdKnownBroken) {
>try {
>sqlType = stmt.getParameterMetaData().getParameterType(i+1);
>} catch (Exception e) { pmdKnownBroken = true; }
>}
>stmt.setNull(i + 1, sqlType);
>
> Possibly we'd add a new argument to the QueryRunner constructor, allowing
> you to set pmdKnownBroken to true right away.
>
/snip

IMHO -- this is a good solution.  Taking advantage of JDBC 3.0 seems like it
would be the right direction to move in rather then implementing spotty
parameter type filler classes.



>
> OPEN QUESTIONS
>
> 1) Will caching this result work?  Will it impact thread-safety in some
> negative way?
>

a)  Yes it should work.
b) Yes it will have a thread safety issue -- you'll need to synchronize on
something when setting the pmdKnownBroken variable.


>
> 2) How do we distinguish between getParameterType failing due to an
> out-of-bounds index, vs. failing due to a broken JDBC driver?  Normally we
> could use ParameterMetaData.getParameterCount() ... does that work on
> Oracle?  I don't have an instance available to test.
>

ParameterMetaData.getParameterCount() works fine, and it works fine on
oracle a well.

Thanks for taking the time to summarize and propose a solution -- hopefully
someone will pick up on your work!

Cheers,
-L

Re: [DbUtils] New Java 5 branch (Was: dbutils) [NC]

[Liam Coughlin]

Thanks Rahul --

Second follow up question -- how do we go about gaining access to the
project if no one steps up?

Cheers,
-Liam

On Thu, Jan 8, 2009 at 1:48 PM, Rahul Akolkar wrote:

>
> Ideally, anyone interested in helping should be on this list, so
> posting here as you did is indeed a good way to go about trying to
> find them.
>
>

Re: [DbUtils] New Java 5 branch (Was: dbutils) [NC]

[Liam Coughlin]

Hello Julien

Branching for java 5 development would be an excellent idea as fulling using
some of the java5 feature set results in some non-trivial changes to some of
the project's structures.

So the follow up question is -- is there a commons committer who's willing
to help us out, and how do we go about finding them?

Cheers,
-Liam Seamus Coughlin

On Thu, Jan 8, 2009 at 3:12 AM, Julien AYME  wrote:

> Hello Liam, hello DbUtils people,
>
> I'd like to contribute in this too, as well as seing some patches being
> analyzed/commited;
> there is a bunch of submitted patched waiting for being reviewed.
> I think that the main issue for dbutils is that there has been little
> activity on this project
> for the last couple years, so we should ask for a commons commiter who is
> willing to help.
>
> As for how we should work, I think it would be usefull to create a J5 or
> J6 branch,
> make the changes in there, and switch the new branch with trunk once it's
> done.
> This would lead to the next major release of DbUtils.
>
> Regards,
> Julien Aymé
>
>
>
>
> "Liam Coughlin" 
> 07/01/2009 21:16
> Please respond to
> "Commons Developers List" 
>
>
>
> To
> dev@commons.apache.org
> cc
>
> Subject
> dbutils
>
>
>
>
>
>
> Hello -- I was curious who currently owned the dbutils package.  I've used
> it extensively on some projects and would like to see it's development
> continue, and in particular, would like to see it updated to use java 5
> features ( generics, etc. ).
>
> I'd be willing to do some of this work, and was hoping to coordinate with
> whoever currently owns the package.
>
> Cheers,
> -Liam Seamus Coughlin
>
> *
> This message and any attachments (the "message") are confidential, intended
> solely for the addressee(s), and may contain legally privileged information.
> Any unauthorised use or dissemination is prohibited. E-mails are
> susceptible to alteration.
> Neither SOCIETE GENERALE nor any of its subsidiaries or affiliates shall be
> liable for the message if altered, changed or
> falsified.
>  
> Ce message et toutes les pieces jointes (ci-apres le "message") sont
> confidentiels et susceptibles de contenir des informations couvertes
> par le secret professionnel.
> Ce message est etabli a l'intention exclusive de ses destinataires. Toute
> utilisation ou diffusion non autorisee est interdite.
> Tout message electronique est susceptible d'alteration.
> La SOCIETE GENERALE et ses filiales declinent toute responsabilite au titre
> de ce message s'il a ete altere, deforme ou falsifie.
> *
>

dbutils

[Liam Coughlin]

Hello -- I was curious who currently owned the dbutils package.  I've used
it extensively on some projects and would like to see it's development
continue, and in particular, would like to see it updated to use java 5
features ( generics, etc. ).

I'd be willing to do some of this work, and was hoping to coordinate with
whoever currently owns the package.

Cheers,
-Liam Seamus Coughlin