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").
Should have said:
...only be used in very few cases (and even less when/if we provide
alternatives
for the important "patterns")
/max
/max
-----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
