Then we need @bad... ;) -----Original Message----- From: hibernate-dev-bounces(a)lists.jboss.org [mailto:hibernate-dev-bounces@lists.jboss.org] On Behalf Of Max Rydahl Andersen Sent: Wednesday, August 30, 2006 3:01 PM To: Christian Bauer; hibernate-dev(a)lists.jboss.org Subject: Re: [hibernate-dev] Connection proxying >> The question was simply whether exposing the >> Work/command APIs justify removal of the connection() method from the >> perspective of using it for direct JDBC work. I do not know that >> answer >> to that. Unfortunately, I suspect it does not and that we will need >> to >> keep connection() around; but one can dream. >> > I'd keep connection() around and not deprecate it, no matter what > better > solutions we find for the various use cases. We can hide it in the API > > documentation and like we do now, document the problems. It's just too > > useful to deprecate it. Also remember the public riots when JDO 1.0 > didn't have an easy way to get a JDBC connection. > I agree this is also a reason/same reason to keep it, but I do think (at least for now ;) that @deprecate would make sense. Not @deprecate as in "it will be removed", but @deprecate as how it is done for e.g. Date and some of its constructors. Those constructors are still around because they are usable in some contexts but with @deprecate it is made explicit and documented that they are 'bad' and what the consequences are for using it.

I would say .connection() falls in some of those categories and should only be used in very few cases (until we provide alternatives for the important "patterns").

/max >> -----Original Message----- >> From: hibernate-dev-bounces(a)lists.jboss.org >> [mailto:hibernate-dev-bounces@lists.jboss.org] On Behalf Of Max Rydahl >> Andersen >> Sent: Wednesday, August 30, 2006 3:01 PM >> To: Christian Bauer; hibernate-dev(a)lists.jboss.org >> Subject: Re: [hibernate-dev] Connection proxying >> >> >> >>>> The question was simply whether exposing the >>>> Work/command APIs justify removal of the connection() method from the >>>> perspective of using it for direct JDBC work. I do not know that >>>> >> answer >> >>>> to that. Unfortunately, I suspect it does not and that we will need >>>> >> to >> >>>> keep connection() around; but one can dream. >>>> >>> I'd keep connection() around and not deprecate it, no matter what >>> >> better >>> solutions we find for the various use cases. We can hide it in the API >>> >> >> >>> documentation and like we do now, document the problems. It's just too >>> >> >> >>> useful to deprecate it. Also remember the public riots when JDO 1.0 >>> didn't have an easy way to get a JDBC connection. >>> >> >> I agree this is also a reason/same reason to keep it, but I do think >> (at >> >> least for now ;) that >> @deprecate would make sense. >> >> Not @deprecate as in "it will be removed", but @deprecate as how it >> is done for e.g. Date and some of its constructors. >> >> Those constructors are still around because they are usable in some >> contexts but with @deprecate it is made explicit and documented >> that they are 'bad' and what the consequences are for using it. >> >>