Then we need @bad... ;) -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Max Rydahl Andersen Sent: Wednesday, August 30, 2006 3:01 PM To: Christian Bauer; hibernate-dev@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. -- -- Max Rydahl Andersen callto://max.rydahl.andersen Hibernate [EMAIL PROTECTED] http://hibernate.org JBoss a division of Red Hat [EMAIL PROTECTED] _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
