Re: [hibernate-dev] Connection proxying
Since the intention is to provide a safer execution for the user then +1,
but if you are going to do this then i guess session.connection() will
still be ok
since it will just be proxied.
btw. your example is a bit simplified since when hibernate runs inside an
appserver
the user will normally also have to cast through the appservers "proxying".
( ( OracleConnection ) (( AppServerConnection ) ( HibernateConnection )
connection ).getWrappedConnection()
).getNativeConnection()).doSomethingOracleSpecific()
...but I guess we will then soon see NativeJdbcExtractorAdapter
implementation for Hibernate ;)
/max
This is in regards to the JDBC interaction code I recently committed
into the sandbox in SVN.
I am considering proxying the JDBC connections specifically for the
purpose of auto-registering "subordinate objects" (result sets and
statements) for automatic cleanup. Currently the registration is a
manual process in order to take advantage of the automatic cleanup (have
a look at org.hibernate.jdbc4.jdbc.impl.BasicWorkTest for the basic
usage pattern). Specifically what I am thinking is taking a page from
how app servers implement Connection handles in relation to data
sources:
public interface HibernateConnection extends java.sql.Connection {
public Connection getWrappedConnection();
}
Of course this makes it more difficult for anyone depending on casting
to a particular driver's Connection impl at some point. But,
considering that this is atypical usage, my thought was to treat it as
the more complex use-case; and since this generally requires casting
anyway, one extra cast and "extraction" is not that big of a deal to me.
For example, to get an oracle connection (for LOB handling for example):
( ( OracleConnection ) connection ).doSomethingOracleSpecific() -> ( (
OracleConnection ) ( ( HibernateConnection ) connection
).getWrappedConnection() ).doSomethingOracleSpecific()
Plus, would potentially allow for some other niceties like automatic
statement logging (perhaps even with parameter replacement).
Thoughts?
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
--
--
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
RE: [hibernate-dev] Connection proxying
Not sure. You know I would love to get rid of Session.connection()
completely. Guess it depends on how clean and generally useful this new
Work and command code becomes.
However, removing that connection() method does additionally create an
issue in regards to how to then deal with the common usage pattern of
"subordinate sessions": sf.openSession( s.connection() )... One thought
was to add either a sf.openSubordinateSession( s ) or even
s.openSubordinateSession()
-Original Message-
From: Max Andersen
Sent: Wednesday, August 30, 2006 2:30 AM
To: Steve Ebersole; hibernate-dev@lists.jboss.org
Subject: Re: [hibernate-dev] Connection proxying
Since the intention is to provide a safer execution for the user then
+1,
but if you are going to do this then i guess session.connection() will
still be ok
since it will just be proxied.
btw. your example is a bit simplified since when hibernate runs inside
an
appserver
the user will normally also have to cast through the appservers
"proxying".
( ( OracleConnection ) (( AppServerConnection ) ( HibernateConnection )
connection ).getWrappedConnection()
).getNativeConnection()).doSomethingOracleSpecific()
...but I guess we will then soon see NativeJdbcExtractorAdapter
implementation for Hibernate ;)
/max
> This is in regards to the JDBC interaction code I recently committed
> into the sandbox in SVN.
>
> I am considering proxying the JDBC connections specifically for the
> purpose of auto-registering "subordinate objects" (result sets and
> statements) for automatic cleanup. Currently the registration is a
> manual process in order to take advantage of the automatic cleanup
(have
> a look at org.hibernate.jdbc4.jdbc.impl.BasicWorkTest for the basic
> usage pattern). Specifically what I am thinking is taking a page from
> how app servers implement Connection handles in relation to data
> sources:
>
> public interface HibernateConnection extends java.sql.Connection {
> public Connection getWrappedConnection();
> }
>
> Of course this makes it more difficult for anyone depending on casting
> to a particular driver's Connection impl at some point. But,
> considering that this is atypical usage, my thought was to treat it as
> the more complex use-case; and since this generally requires casting
> anyway, one extra cast and "extraction" is not that big of a deal to
me.
> For example, to get an oracle connection (for LOB handling for
example):
> ( ( OracleConnection ) connection ).doSomethingOracleSpecific() -> ( (
> OracleConnection ) ( ( HibernateConnection ) connection
> ).getWrappedConnection() ).doSomethingOracleSpecific()
>
> Plus, would potentially allow for some other niceties like automatic
> statement logging (perhaps even with parameter replacement).
>
> Thoughts?
>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
--
--
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
Re: [hibernate-dev] Connection proxying
However, removing that connection() method does additionally create an
issue in regards to how to then deal with the common usage pattern of
"subordinate sessions": sf.openSession( s.connection() )... One thought
was to add either a sf.openSubordinateSession( s ) or even
s.openSubordinateSession()
and...
openSubordinateSession(Interceptor)
openSubordinateStatelessSession()
its a loong name...and isn't the session one gets from getSession a more
true
"subordinate" ?
Needs a better nameor maybe just keep session.connection() around ? :)
What are the arguments *against* session.connection() if you do the
proxying you
are suggesting ?
/max
-Original Message-
From: Max Andersen
Sent: Wednesday, August 30, 2006 2:30 AM
To: Steve Ebersole; hibernate-dev@lists.jboss.org
Subject: Re: [hibernate-dev] Connection proxying
Since the intention is to provide a safer execution for the user then
+1,
but if you are going to do this then i guess session.connection() will
still be ok
since it will just be proxied.
btw. your example is a bit simplified since when hibernate runs inside
an
appserver
the user will normally also have to cast through the appservers
"proxying".
( ( OracleConnection ) (( AppServerConnection ) ( HibernateConnection )
connection ).getWrappedConnection()
).getNativeConnection()).doSomethingOracleSpecific()
...but I guess we will then soon see NativeJdbcExtractorAdapter
implementation for Hibernate ;)
/max
This is in regards to the JDBC interaction code I recently committed
into the sandbox in SVN.
I am considering proxying the JDBC connections specifically for the
purpose of auto-registering "subordinate objects" (result sets and
statements) for automatic cleanup. Currently the registration is a
manual process in order to take advantage of the automatic cleanup
(have
a look at org.hibernate.jdbc4.jdbc.impl.BasicWorkTest for the basic
usage pattern). Specifically what I am thinking is taking a page from
how app servers implement Connection handles in relation to data
sources:
public interface HibernateConnection extends java.sql.Connection {
public Connection getWrappedConnection();
}
Of course this makes it more difficult for anyone depending on casting
to a particular driver's Connection impl at some point. But,
considering that this is atypical usage, my thought was to treat it as
the more complex use-case; and since this generally requires casting
anyway, one extra cast and "extraction" is not that big of a deal to
me.
For example, to get an oracle connection (for LOB handling for
example):
( ( OracleConnection ) connection ).doSomethingOracleSpecific() -> ( (
OracleConnection ) ( ( HibernateConnection ) connection
).getWrappedConnection() ).doSomethingOracleSpecific()
Plus, would potentially allow for some other niceties like automatic
statement logging (perhaps even with parameter replacement).
Thoughts?
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
--
--
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
RE: [hibernate-dev] Connection proxying
Imagine this usage:
Session s = ...;
Connection c = s.connection();
PS stmnt = c.prepareStatement( ... );
RS rs = stmnt.executeQuery();
s.load( ... );
rs.next();
...
Seems harmless enough, right? Will it work? Answer: well it depends ;)
Both the ConnectionProvider being used and the connection release mode
configured play parts in this (which is a PIA to explain and even more
so to justify). This is exactly the scenario which forced me to add the
notion of BorrowedConnectionProxy to the core as it is now in the first
place, so that the behavior could be consistent; the downside is that it
essentially overrides *any* connection releasing.
But, regardless, I do not like exposing the connection for "unbounded"
use. It leads to too many quirks and difficulties like the one
mentioned above. I think it really comes down to the answer to this
question:
If you as a user are doing some work with the connection obtained from a
Hibernate Session, how big of a disruption is it to change from that
usage pattern to this new usage pattern. And whether than disruption is
then adequately offset by any advantages of this new usage pattern.
And to be clear, what I am talking about is along the lines of...
Old:
Connection c = session.connection();
try {
// do work with the connection
}
catch( SQLException sqle ) {
...
}
finally {
c.close();
}
New:
session.doWork(
new Work() {
public void performWork(Workspace workspace) {
Connection c = workspace.getConnection();
// do work with the connection
}
}
);
The advantages are the typical "avoid tedious error handling", "avoid
redundant resource management", blah-blah-blah you heard from every
other library supporting delegation/templating solutions to JDBC access.
Additionally, you get integration with our notion of connection release
modes, exception conversion, logging, etc. Some of those "extras" could
be achieved even via exposing the proxy rather than the "raw"
connection, but the connection release modes are explicitly
circumvented...
-Original Message-
From: Max Andersen
Sent: Wednesday, August 30, 2006 9:09 AM
To: Steve Ebersole
Cc: hibernate-dev@lists.jboss.org
Subject: Re: [hibernate-dev] Connection proxying
> However, removing that connection() method does additionally create an
> issue in regards to how to then deal with the common usage pattern of
> "subordinate sessions": sf.openSession( s.connection() )... One
thought
> was to add either a sf.openSubordinateSession( s ) or even
> s.openSubordinateSession()
and...
openSubordinateSession(Interceptor)
openSubordinateStatelessSession()
its a loong name...and isn't the session one gets from getSession a more
true
"subordinate" ?
Needs a better nameor maybe just keep session.connection() around ?
:)
What are the arguments *against* session.connection() if you do the
proxying you
are suggesting ?
/max
> -Original Message-
> From: Max Andersen
> Sent: Wednesday, August 30, 2006 2:30 AM
> To: Steve Ebersole; hibernate-dev@lists.jboss.org
> Subject: Re: [hibernate-dev] Connection proxying
>
> Since the intention is to provide a safer execution for the user then
> +1,
> but if you are going to do this then i guess session.connection() will
> still be ok
> since it will just be proxied.
>
> btw. your example is a bit simplified since when hibernate runs inside
> an
> appserver
> the user will normally also have to cast through the appservers
> "proxying".
>
> ( ( OracleConnection ) (( AppServerConnection ) ( HibernateConnection
)
>
> connection ).getWrappedConnection()
> ).getNativeConnection()).doSomethingOracleSpecific()
>
> ...but I guess we will then soon see NativeJdbcExtractorAdapter
> implementation for Hibernate ;)
>
> /max
>
>
>
>> This is in regards to the JDBC interaction code I recently committed
>> into the sandbox in SVN.
>>
>> I am considering proxying the JDBC connections specifically for the
>> purpose of auto-registering "subordinate objects" (result sets and
>> statements) for automatic cleanup. Currently the registration is a
>> manual process in order to take advantage of the automatic cleanup
> (have
>> a look at org.hibernate.jdbc4.jdbc.impl.BasicWorkTest for the basic
>> usage pattern). Specifically what I am thinking is taking a page
from
>> how app servers implement Connection handles in relation to data
>> sources:
>>
>> public interface HibernateConnection extends java.sql.Connection {
>> public Connection getWrappedConnection();
>> }
>>
>> Of course this makes it more difficult for anyone depending on
casting
>> to a particular driver's Connection impl at some point. But,
>> considering that this is atypical usage, my thought was to treat it
as
>> the more complex use-case; and since this generally requires casting
>> anyway, one extra cast and "extraction" is not that big of a deal to
> me.
>> For example, to get an oracle connection (for LOB handling for
> example):
>> ( ( OracleCon
Re: [hibernate-dev] Connection proxying
session.connection() is completely useless in a JavaEE environment
@Resource Connection connection;
is much better
Max Rydahl Andersen wrote:
However, removing that connection() method does additionally create an
issue in regards to how to then deal with the common usage pattern of
"subordinate sessions": sf.openSession( s.connection() )... One thought
was to add either a sf.openSubordinateSession( s ) or even
s.openSubordinateSession()
and...
openSubordinateSession(Interceptor)
openSubordinateStatelessSession()
its a loong name...and isn't the session one gets from getSession a
more true
"subordinate" ?
Needs a better nameor maybe just keep session.connection() around
? :)
What are the arguments *against* session.connection() if you do the
proxying you
are suggesting ?
/max
-Original Message-
From: Max Andersen
Sent: Wednesday, August 30, 2006 2:30 AM
To: Steve Ebersole; hibernate-dev@lists.jboss.org
Subject: Re: [hibernate-dev] Connection proxying
Since the intention is to provide a safer execution for the user then
+1,
but if you are going to do this then i guess session.connection() will
still be ok
since it will just be proxied.
btw. your example is a bit simplified since when hibernate runs inside
an
appserver
the user will normally also have to cast through the appservers
"proxying".
( ( OracleConnection ) (( AppServerConnection ) ( HibernateConnection )
connection ).getWrappedConnection()
).getNativeConnection()).doSomethingOracleSpecific()
...but I guess we will then soon see NativeJdbcExtractorAdapter
implementation for Hibernate ;)
/max
This is in regards to the JDBC interaction code I recently committed
into the sandbox in SVN.
I am considering proxying the JDBC connections specifically for the
purpose of auto-registering "subordinate objects" (result sets and
statements) for automatic cleanup. Currently the registration is a
manual process in order to take advantage of the automatic cleanup
(have
a look at org.hibernate.jdbc4.jdbc.impl.BasicWorkTest for the basic
usage pattern). Specifically what I am thinking is taking a page from
how app servers implement Connection handles in relation to data
sources:
public interface HibernateConnection extends java.sql.Connection {
public Connection getWrappedConnection();
}
Of course this makes it more difficult for anyone depending on casting
to a particular driver's Connection impl at some point. But,
considering that this is atypical usage, my thought was to treat it as
the more complex use-case; and since this generally requires casting
anyway, one extra cast and "extraction" is not that big of a deal to
me.
For example, to get an oracle connection (for LOB handling for
example):
( ( OracleConnection ) connection ).doSomethingOracleSpecific() -> ( (
OracleConnection ) ( ( HibernateConnection ) connection
).getWrappedConnection() ).doSomethingOracleSpecific()
Plus, would potentially allow for some other niceties like automatic
statement logging (perhaps even with parameter replacement).
Thoughts?
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
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
Re: [hibernate-dev] Connection proxying
session.connection() is completely useless in a JavaEE environment
@Resource Connection connection;
is much better
and your point is ?
Tell me again how I get the connection injected into e.g. a Hibernate
interceptor ?
or in plain j2se etc. ;)
/max
Max Rydahl Andersen wrote:
However, removing that connection() method does additionally create an
issue in regards to how to then deal with the common usage pattern of
"subordinate sessions": sf.openSession( s.connection() )... One
thought
was to add either a sf.openSubordinateSession( s ) or even
s.openSubordinateSession()
and...
openSubordinateSession(Interceptor)
openSubordinateStatelessSession()
its a loong name...and isn't the session one gets from getSession a
more true
"subordinate" ?
Needs a better nameor maybe just keep session.connection() around ?
:)
What are the arguments *against* session.connection() if you do the
proxying you
are suggesting ?
/max
-Original Message-
From: Max Andersen
Sent: Wednesday, August 30, 2006 2:30 AM
To: Steve Ebersole; hibernate-dev@lists.jboss.org
Subject: Re: [hibernate-dev] Connection proxying
Since the intention is to provide a safer execution for the user then
+1,
but if you are going to do this then i guess session.connection() will
still be ok
since it will just be proxied.
btw. your example is a bit simplified since when hibernate runs inside
an
appserver
the user will normally also have to cast through the appservers
"proxying".
( ( OracleConnection ) (( AppServerConnection ) ( HibernateConnection
)
connection ).getWrappedConnection()
).getNativeConnection()).doSomethingOracleSpecific()
...but I guess we will then soon see NativeJdbcExtractorAdapter
implementation for Hibernate ;)
/max
This is in regards to the JDBC interaction code I recently committed
into the sandbox in SVN.
I am considering proxying the JDBC connections specifically for the
purpose of auto-registering "subordinate objects" (result sets and
statements) for automatic cleanup. Currently the registration is a
manual process in order to take advantage of the automatic cleanup
(have
a look at org.hibernate.jdbc4.jdbc.impl.BasicWorkTest for the basic
usage pattern). Specifically what I am thinking is taking a page from
how app servers implement Connection handles in relation to data
sources:
public interface HibernateConnection extends java.sql.Connection {
public Connection getWrappedConnection();
}
Of course this makes it more difficult for anyone depending on casting
to a particular driver's Connection impl at some point. But,
considering that this is atypical usage, my thought was to treat it as
the more complex use-case; and since this generally requires casting
anyway, one extra cast and "extraction" is not that big of a deal to
me.
For example, to get an oracle connection (for LOB handling for
example):
( ( OracleConnection ) connection ).doSomethingOracleSpecific() -> ( (
OracleConnection ) ( ( HibernateConnection ) connection
).getWrappedConnection() ).doSomethingOracleSpecific()
Plus, would potentially allow for some other niceties like automatic
statement logging (perhaps even with parameter replacement).
Thoughts?
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
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
--
--
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] Insert not working
Hi,I have just started working on hibernate. I was trying to start with some sample applications.I am facing this problem when I am trying to insert data. It does not throw any error but does not do any insert.
I can easily fetch information using the same mapping.Can someone help me with this.I am using MYSQL5 with hibernate 3My hibernate-cfg.xml loooks like following
"-//Hibernate/Hibernate Configuration DTD//EN""http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd
"> com.mysql.jdbc.Driver jdbc:mysql://localhost/test root 10 true
org.hibernate.dialect.MySQLDialect
my contact.hbm.xml looks like "-//Hibernate/Hibernate Mapping DTD 3.0//EN" "
http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">
The Java Code looks like the followingSessionFactory factory = null; try
{ Configuration cfg = new Configuration(); factory = cfg.configure().buildSessionFactory(); Session session = factory.openSession(); notification_email ne = createNotificationEmail();
session.save(ne); session.flush(); session.close(); } catch(Exception e) { System.out.println(""+e);
e.printStackTrace(); }I will greatly appreciate if someone can provide me an answer. Really struggling. thanks-- Dinesh Chaturvedi
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Connection proxying
Session s = ...;
Connection c = s.connection();
PS stmnt = c.prepareStatement( ... );
RS rs = stmnt.executeQuery();
s.load( ... );
rs.next();
...
Seems harmless enough, right? Will it work? Answer: well it depends ;)
Both the ConnectionProvider being used and the connection release mode
configured play parts in this (which is a PIA to explain and even more
so to justify). This is exactly the scenario which forced me to add the
notion of BorrowedConnectionProxy to the core as it is now in the first
place, so that the behavior could be consistent; the downside is that it
essentially overrides *any* connection releasing.
ah yes - it comes down to the release mode. Now I remember.
so should we start by @deprecate connection() in 3.2 ?
We don't really have any other portable way of exposing the connection
running the same tx as the session.
If you as a user are doing some work with the connection obtained from a
Hibernate Session, how big of a disruption is it to change from that
usage pattern to this new usage pattern. And whether than disruption is
then adequately offset by any advantages of this new usage pattern.
Yes, and for the usecase of simply getting a connection and do a "one-off"
task
the change is not a big deal.
The issue comes when you are in the scenario of having mixed Hibernate and
JDBC code;
here getting access to a shared connection is good (session.connection()
is one, openSession(connection) is another and ConnectionProvider is a
third)
But I would argue all three are relevant, but I would also be completely
fine
by giving those who want to have "unbounded" access a bigger burden ..e.g.
remembering to close the connection,
live with releasemode being circumvented etc.
The advantages are the typical "avoid tedious error handling", "avoid
redundant resource management", blah-blah-blah you heard from every
other library supporting delegation/templating solutions to JDBC access.
Additionally, you get integration with our notion of connection release
modes, exception conversion, logging, etc. Some of those "extras" could
be achieved even via exposing the proxy rather than the "raw"
connection, but the connection release modes are explicitly
circumvented...
I don't talk against having the new thing exposed, fine by me.
I just think there still is a important "niche" usage for
session.connection(). (not forgetting many books, training, examples,
applications that refers to this method)
On that note:
Will the following snippet be equal to c = session.connection() ?
final Connection[] c = new Connection[1];
session.doWork(
new Work() {
public void performWork(Workspace workspace) {
c[0] = workspace.getConnection();
}
}
);
/max
-Original Message-
From: Max Andersen
Sent: Wednesday, August 30, 2006 9:09 AM
To: Steve Ebersole
Cc: hibernate-dev@lists.jboss.org
Subject: Re: [hibernate-dev] Connection proxying
However, removing that connection() method does additionally create an
issue in regards to how to then deal with the common usage pattern of
"subordinate sessions": sf.openSession( s.connection() )... One
thought
was to add either a sf.openSubordinateSession( s ) or even
s.openSubordinateSession()
and...
openSubordinateSession(Interceptor)
openSubordinateStatelessSession()
its a loong name...and isn't the session one gets from getSession a more
true
"subordinate" ?
Needs a better nameor maybe just keep session.connection() around ?
:)
What are the arguments *against* session.connection() if you do the
proxying you
are suggesting ?
/max
-Original Message-
From: Max Andersen
Sent: Wednesday, August 30, 2006 2:30 AM
To: Steve Ebersole; hibernate-dev@lists.jboss.org
Subject: Re: [hibernate-dev] Connection proxying
Since the intention is to provide a safer execution for the user then
+1,
but if you are going to do this then i guess session.connection() will
still be ok
since it will just be proxied.
btw. your example is a bit simplified since when hibernate runs inside
an
appserver
the user will normally also have to cast through the appservers
"proxying".
( ( OracleConnection ) (( AppServerConnection ) ( HibernateConnection
)
connection ).getWrappedConnection()
).getNativeConnection()).doSomethingOracleSpecific()
...but I guess we will then soon see NativeJdbcExtractorAdapter
implementation for Hibernate ;)
/max
This is in regards to the JDBC interaction code I recently committed
into the sandbox in SVN.
I am considering proxying the JDBC connections specifically for the
purpose of auto-registering "subordinate objects" (result sets and
statements) for automatic cleanup. Currently the registration is a
manual process in order to take advantage of the automatic cleanup
(have
a look at org.hibernate.jdbc4.jdbc.impl.BasicWorkTest for the basic
usage pattern). Specifically what I am thinking is taking a page
from
how app servers implement Connection handles in re
Re: [hibernate-dev] Insert not working
http://forum.hibernate.org
/max
Hi,
I have just started working on hibernate. I was trying to start with some
sample applications.
I am facing this problem when I am trying to insert data. It does not
throw
any error but does not do any insert.
I can easily fetch information using the same mapping.
Can someone help me with this.
I am using MYSQL5 with hibernate 3
My hibernate-cfg.xml loooks like following
http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd";>
com.mysql.jdbc.Driver
jdbc:mysql://localhost/test
root
10
true
name="dialect">org.hibernate.dialect.MySQLDialect
my contact.hbm.xml looks like
http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd";>
The Java Code looks like the following
SessionFactory factory = null;
try
{
Configuration cfg = new Configuration();
factory = cfg.configure().buildSessionFactory();
Session session = factory.openSession();
notification_email ne = createNotificationEmail();
session.save(ne);
session.flush();
session.close();
}
catch(Exception e)
{
System.out.println(""+e);
e.printStackTrace();
}
I will greatly appreciate if someone can provide me an answer. Really
struggling. thanks
--
--
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
RE: [hibernate-dev] Connection proxying
Depends... Do you mean the current session.connection()? If so, then
no, they will not be the same. Currently, session.connection() enforces
that the connection is usable until (1) the connection is "closed" or
(2) the transaction ends. If you tried the Work code you listed, that
guarantee would not hold; the connection is only guaranteed to be valid
during the performWork() call.
No one is saying (at least I don't think so) that either of those cases
is unimportant (I actually do not understand how your ConnectionProvider
reference fits there though). On the contrary, I specifically said we
would need a plan for handling the sf.openSession( s.connection() ) case
in my original e-mail. 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.
-Original Message-
From: Max Andersen
Sent: Wednesday, August 30, 2006 12:08 PM
To: Steve Ebersole
Cc: hibernate-dev@lists.jboss.org
Subject: Re: [hibernate-dev] Connection proxying
> Session s = ...;
> Connection c = s.connection();
> PS stmnt = c.prepareStatement( ... );
> RS rs = stmnt.executeQuery();
> s.load( ... );
> rs.next();
> ...
>
> Seems harmless enough, right? Will it work? Answer: well it depends
;)
> Both the ConnectionProvider being used and the connection release mode
> configured play parts in this (which is a PIA to explain and even more
> so to justify). This is exactly the scenario which forced me to add
the
> notion of BorrowedConnectionProxy to the core as it is now in the
first
> place, so that the behavior could be consistent; the downside is that
it
> essentially overrides *any* connection releasing.
ah yes - it comes down to the release mode. Now I remember.
so should we start by @deprecate connection() in 3.2 ?
We don't really have any other portable way of exposing the connection
running the same tx as the session.
> If you as a user are doing some work with the connection obtained from
a
> Hibernate Session, how big of a disruption is it to change from that
> usage pattern to this new usage pattern. And whether than disruption
is
> then adequately offset by any advantages of this new usage pattern.
Yes, and for the usecase of simply getting a connection and do a
"one-off"
task
the change is not a big deal.
The issue comes when you are in the scenario of having mixed Hibernate
and
JDBC code;
here getting access to a shared connection is good (session.connection()
is one, openSession(connection) is another and ConnectionProvider is a
third)
But I would argue all three are relevant, but I would also be completely
fine
by giving those who want to have "unbounded" access a bigger burden
..e.g.
remembering to close the connection,
live with releasemode being circumvented etc.
> The advantages are the typical "avoid tedious error handling", "avoid
> redundant resource management", blah-blah-blah you heard from every
> other library supporting delegation/templating solutions to JDBC
access.
> Additionally, you get integration with our notion of connection
release
> modes, exception conversion, logging, etc. Some of those "extras"
could
> be achieved even via exposing the proxy rather than the "raw"
> connection, but the connection release modes are explicitly
> circumvented...
I don't talk against having the new thing exposed, fine by me.
I just think there still is a important "niche" usage for
session.connection(). (not forgetting many books, training, examples,
applications that refers to this method)
On that note:
Will the following snippet be equal to c = session.connection() ?
final Connection[] c = new Connection[1];
session.doWork(
new Work() {
public void performWork(Workspace workspace) {
c[0] = workspace.getConnection();
}
}
);
/max
>
> -Original Message-
> From: Max Andersen
> Sent: Wednesday, August 30, 2006 9:09 AM
> To: Steve Ebersole
> Cc: hibernate-dev@lists.jboss.org
> Subject: Re: [hibernate-dev] Connection proxying
>
>
>> However, removing that connection() method does additionally create
an
>> issue in regards to how to then deal with the common usage pattern of
>> "subordinate sessions": sf.openSession( s.connection() )... One
> thought
>> was to add either a sf.openSubordinateSession( s ) or even
>> s.openSubordinateSession()
>
> and...
> openSubordinateSession(Interceptor)
> openSubordinateStatelessSession()
>
> its a loong name...and isn't the session one gets from getSession a
more
>
> true
> "subordinate" ?
>
> Needs a better nameor maybe just keep session.connection() around
?
> :)
>
> What are the arguments *against* session.connection() if you do the
> proxying you
> are suggesting ?
>
> /max
>
>> -Original Message-
>> From: Max Andersen
>> Sent: Wednesday, A
Re: [hibernate-dev] Connection proxying
On Aug 30, 2006, at 9:39 PM, Steve Ebersole wrote: 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. ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Connection proxying
So I think we agree (just using different words ;)
Something like the Worker would be beneficial and s.getNewSession() might
be an alternative to sf.openSession( s.connection() ).
and session.connection() probably has to stick around as a necessary evil
for some usecases.
When do you plan for Worker to be included ? 3.2.x ? 3.3 ?
Will it make sense to @deprecate session.connection() now for 3.2,
documenting very explicitly
what alternatives there is etc.?
/max
Depends... Do you mean the current session.connection()? If so, then
no, they will not be the same. Currently, session.connection() enforces
that the connection is usable until (1) the connection is "closed" or
(2) the transaction ends. If you tried the Work code you listed, that
guarantee would not hold; the connection is only guaranteed to be valid
during the performWork() call.
No one is saying (at least I don't think so) that either of those cases
is unimportant (I actually do not understand how your ConnectionProvider
reference fits there though). On the contrary, I specifically said we
would need a plan for handling the sf.openSession( s.connection() ) case
in my original e-mail. 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.
-Original Message-
From: Max Andersen
Sent: Wednesday, August 30, 2006 12:08 PM
To: Steve Ebersole
Cc: hibernate-dev@lists.jboss.org
Subject: Re: [hibernate-dev] Connection proxying
Session s = ...;
Connection c = s.connection();
PS stmnt = c.prepareStatement( ... );
RS rs = stmnt.executeQuery();
s.load( ... );
rs.next();
...
Seems harmless enough, right? Will it work? Answer: well it depends
;)
Both the ConnectionProvider being used and the connection release mode
configured play parts in this (which is a PIA to explain and even more
so to justify). This is exactly the scenario which forced me to add
the
notion of BorrowedConnectionProxy to the core as it is now in the
first
place, so that the behavior could be consistent; the downside is that
it
essentially overrides *any* connection releasing.
ah yes - it comes down to the release mode. Now I remember.
so should we start by @deprecate connection() in 3.2 ?
We don't really have any other portable way of exposing the connection
running the same tx as the session.
If you as a user are doing some work with the connection obtained from
a
Hibernate Session, how big of a disruption is it to change from that
usage pattern to this new usage pattern. And whether than disruption
is
then adequately offset by any advantages of this new usage pattern.
Yes, and for the usecase of simply getting a connection and do a
"one-off"
task
the change is not a big deal.
The issue comes when you are in the scenario of having mixed Hibernate
and
JDBC code;
here getting access to a shared connection is good (session.connection()
is one, openSession(connection) is another and ConnectionProvider is a
third)
But I would argue all three are relevant, but I would also be completely
fine
by giving those who want to have "unbounded" access a bigger burden
..e.g.
remembering to close the connection,
live with releasemode being circumvented etc.
The advantages are the typical "avoid tedious error handling", "avoid
redundant resource management", blah-blah-blah you heard from every
other library supporting delegation/templating solutions to JDBC
access.
Additionally, you get integration with our notion of connection
release
modes, exception conversion, logging, etc. Some of those "extras"
could
be achieved even via exposing the proxy rather than the "raw"
connection, but the connection release modes are explicitly
circumvented...
I don't talk against having the new thing exposed, fine by me.
I just think there still is a important "niche" usage for
session.connection(). (not forgetting many books, training, examples,
applications that refers to this method)
On that note:
Will the following snippet be equal to c = session.connection() ?
final Connection[] c = new Connection[1];
session.doWork(
new Work() {
public void performWork(Workspace workspace) {
c[0] = workspace.getConnection();
}
}
);
/max
-Original Message-
From: Max Andersen
Sent: Wednesday, August 30, 2006 9:09 AM
To: Steve Ebersole
Cc: hibernate-dev@lists.jboss.org
Subject: Re: [hibernate-dev] Connection proxying
However, removing that connection() method does additionally create
an
issue in regards to how to then deal with the common usage pattern of
"subordinate sessions": sf.openSession( s.connection() )... One
thought
was to add either a sf.openSubordinateSession( s ) or even
s.openSubordinateSession()
and...
openSubordinateSession(Interceptor)
open
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
RE: [hibernate-dev] Connection proxying
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
Re: [hibernate-dev] Connection proxying
You should contribute to http://www.jcp.org/en/jsr/detail?id=305 ;-p Steve Ebersole wrote: 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. ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] hibernate-hsqldb-testsuite Build Completed With Testsuite Errors
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/hibernate-hsqldb-testsuite?log=log20060830215954 TESTS FAILEDAnt Error Message: /home/cruisecontrol/work/scripts/build-hibernate-db-matrix.xml:92: The following error occurred while executing this line: /home/cruisecontrol/work/scripts/build-hibernate-db-matrix.xml:83: The following error occurred while executing this line: /home/cruisecontrol/work/scripts/build-common-targets.xml:11: Build Successful - Tests completed with errors or failures.Date of build: 08/30/2006 21:59:54Time to build: 9 minutes 50 secondsLast changed: 12/31/2005 20:44:14Last log entry: less noisy Unit Tests: (901) Total Errors and Failures: (2)testReturnPropertyComponentRenameorg.hibernate.test.legacy.SQLLoaderTesttestAutoDetectAliasingorg.hibernate.test.sql.GeneralTest Modifications since last build: (first 50 of 1896)10381addedhonma//trunk/Hibernate3/doc/reference/ja/fop/sazanami-gothic.ttf10381addedhonma//trunk/Hibernate3/doc/reference/ja/fop/sazanami-mincho.ttf10381addedhonma//trunk/Hibernate3/doc/reference/ja/fop/sazanami-gothic.xml10381addedhonma//trunk/Hibernate3/doc/reference/ja/fop/sazanami-mincho.xml10380modifiedhonma//trunk/Hibernate3/doc/reference/ja/fop/userconfig.xmlchange fonts to use sazanami-font10374deleted[EMAIL PROTECTED]//trunk/Hibernate3/doc/reference/ko/fop/Gaeul.ttfDeleted MSFT fonts10374deleted[EMAIL PROTECTED]//trunk/Hibernate3/doc/reference/ko/fop/Gaeul.xmlDeleted MSFT fonts10374deleted[EMAIL PROTECTED]//trunk/Hibernate3/doc/reference/ko/fop/Gulim.xmlDeleted MSFT fonts10374deleted[EMAIL PROTECTED]//trunk/Hibernate3/doc/reference/zh-cn/fop/simsun.ttcDeleted MSFT fonts10374deleted[EMAIL PROTECTED]//trunk/Hibernate3/doc/reference/zh-cn/fop/simhei.ttfDeleted MSFT fonts10374modified[EMAIL PROTECTED]//trunk/Hibernate3/doc/reference/build.xmlDeleted MSFT fonts10374deleted[EMAIL PROTECTED]//trunk/Hibernate3/doc/reference/zh-cn/fop/simhei.xmlDeleted MSFT fonts10374deleted[EMAIL PROTECTED]//trunk/Hibernate3/doc/reference/zh-cn/fop/simsun.xmlDeleted MSFT fonts10374deleted[EMAIL PROTECTED]//trunk/Hibernate3/doc/reference/ko/fop/gulim.ttcDeleted MSFT fonts10371modified[EMAIL PROTECTED]//trunk/Hibernate3/doc/reference/fr/styles/fopdf.xslDisable hyphenation10361modifiedepbernard//trunk/Hibernate3/src/org/hibernate/cfg/Mappings.javaGet rid of the private attributes: too hard for annotations10361addedepbernard//trunk/Hibernate3/test/org/hibernate/test/boaGet rid of the private attributes: too hard for annotations10347modified[EMAIL PROTECTED]//trunk/Hibernate3/src/org/hibernate/transaction/JTATransactionFactory.javaHHH-2023 : perf optimization in JTATransactionFactory.isTransactionInProgress()10328deleted[EMAIL PROTECTED]//trunk/Hibernate3/doc/reference/ja/fop/msgothic.xmlHB-156610328deleted[EMAIL PROTECTED]//trunk/Hibernate3/doc/reference/ja/fop/msmincho.xmlHB-156610328deleted[EMAIL PROTECTED]//trunk/Hibernate3/doc/reference/ja/fop/MSMINCHO.TTCHB-156610328deleted[EMAIL PROTECTED]//trunk/Hibernate3/doc/reference/ja/fop/msgothic.ttcHB-156610325modified[EMAIL PROTECTED]//trunk/Hibernate3/lib/version.propertiesHHH-2001 : upgrade javassist10325modified[EMAIL PROTECTED]//trunk/Hibernate3/lib/javassist.jarHHH-2001 : upgrade javassist10322modified[EMAIL PROTECTED]//trunk/Hibernate3/src/org/hibernate/bytecode/javassist/BulkAccessorFactory.javaHHH-2001 : upgrade javassist10320modifiedepbernard//trunk/Hibernate3/src/org/hibernate/mapping/PersistentClass.javaANN-381 add identifierProperty to getProperty and getRecursiveProperty10315modified[EMAIL PROTECTED]//trunk/Hibernate3/src/org/hibernate/util/StringHelper.javaHHH-2022 : property names with leading underscores10314modified[EMAIL PROTECTED]//trunk/Hibernate3/test/org/hibernate/test/util/StringHelperTest.javaHHH-2022 : property names with leading underscores10314modified[EMAIL PROTECTED]//trunk/Hibernate3/test/org/hibernate/test/util/UtilSuite.javaHHH-2022 : property names with leading underscores10313added[EMAIL PROTECTED]//trunk/Hibernate3/test/org/hibernate/test/util/StringHelperTest.javaHHH-2022 : property names with leading underscores10312modified[EMAIL PROTECTED]//trunk/Hibernate3/src/org/hibernate/TransactionException.javaallow nested exception10310modified[EMAIL PROTECTED]//trunk/Hibernate3/src/org/hibernate/engine/CascadingAction.javacleanup10310modified[EMAIL PROTECTED]//trunk/Hibernate3/src/org/hibernate/engine/Cascade.javacleanup10308modified[EMAIL PROTECTED]//trunk/Hibernate3/src/org/hibernate/hibernate-mapping-3.0.dtdHHH-1470 : collection DTD definition10306modified[EMAIL PROTECTED]//trunk/Hibernate3/src/org/hibernate/dialect/Dialect.javaHHH-1806 : java.sql.Types.DECIMAL mappings10306modified[EMAIL PROTECTED]//trunk/Hibernate3/src/org/hibernate/dialect/Oracle9Dialect.javaHHH-1806 : java.sql.Types.DECIMAL mappings10300modified[EMAIL PROTECTED]//trunk/Hibernate3/src/org/hibernate/dialec
[hibernate-dev] hibernate-mysql-testsuite Build Completed With Testsuite Errors
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/hibernate-mysql-testsuite?log=log20060830232053 TESTS FAILEDAnt Error Message: /home/cruisecontrol/work/scripts/build-hibernate-db-matrix.xml:127: The following error occurred while executing this line: /home/cruisecontrol/work/scripts/build-hibernate-db-matrix.xml:83: The following error occurred while executing this line: /home/cruisecontrol/work/scripts/build-common-targets.xml:11: Build Successful - Tests completed with errors or failures.Date of build: 08/30/2006 23:20:53Time to build: 44 minutes 27 secondsLast changed: 12/31/2005 20:44:14Last log entry: less noisy Unit Tests: (899) Total Errors and Failures: (43)testComponentQueriesorg.hibernate.test.hql.ASTParserLoadingTesttestCollectionFetchWithDistinctionAndLimitorg.hibernate.test.hql.ASTParserLoadingTesttestTempTableGenerationIsolationorg.hibernate.test.hql.BulkManipulationTesttestBooleanHandlingorg.hibernate.test.hql.BulkManipulationTesttestSimpleInsertorg.hibernate.test.hql.BulkManipulationTesttestSimpleNativeSQLInsertorg.hibernate.test.hql.BulkManipulationTesttestInsertWithManyToOneorg.hibernate.test.hql.BulkManipulationTesttestInsertWithMismatchedTypesorg.hibernate.test.hql.BulkManipulationTesttestInsertIntoSuperclassPropertiesFailsorg.hibernate.test.hql.BulkManipulationTesttestInsertAcrossMappedJoinFailsorg.hibernate.test.hql.BulkManipulationTesttestUpdateWithWhereExistsSubqueryorg.hibernate.test.hql.BulkManipulationTesttestUpdateOnComponentorg.hibernate.test.hql.BulkManipulationTesttestUpdateOnManyToOneorg.hibernate.test.hql.BulkManipulationTesttestUpdateOnImplicitJoinFailsorg.hibernate.test.hql.BulkManipulationTesttestUpdateOnDiscriminatorSubclassorg.hibernate.test.hql.BulkManipulationTesttestUpdateOnAnimalorg.hibernate.test.hql.BulkManipulationTesttestUpdateOnMammalorg.hibernate.test.hql.BulkManipulationTesttestUpdateSetNullUnionSubclassorg.hibernate.test.hql.BulkManipulationTesttestUpdateSetNullOnDiscriminatorSubclassorg.hibernate.test.hql.BulkManipulationTesttestUpdateSetNullOnJoinedSubclassorg.hibernate.test.hql.BulkManipulationTesttestDeleteOnDiscriminatorSubclassorg.hibernate.test.hql.BulkManipulationTesttestDeleteOnJoinedSubclassorg.hibernate.test.hql.BulkManipulationTesttestDeleteOnMappedJoinorg.hibernate.test.hql.BulkManipulationTesttestDeleteUnionSubclassAbstractRootorg.hibernate.test.hql.BulkManipulationTesttestDeleteUnionSubclassConcreteSubclassorg.hibernate.test.hql.BulkManipulationTesttestDeleteUnionSubclassLeafSubclassorg.hibernate.test.hql.BulkManipulationTesttestDeleteWithMetadataWhereFragmentsorg.hibernate.test.hql.BulkManipulationTesttestDeleteRestrictedOnManyToOneorg.hibernate.test.hql.BulkManipulationTesttestScrollingJoinFetchesForwardorg.hibernate.test.hql.ScrollableCollectionFetchingTesttestScrollingJoinFetchesReverseorg.hibernate.test.hql.ScrollableCollectionFetchingTesttestScrollingJoinFetchesPositioningorg.hibernate.test.hql.ScrollableCollectionFetchingTesttestWithClauseFailsWithFetchorg.hibernate.test.hql.WithClauseTesttestWithClauseorg.hibernate.test.hql.WithClauseTesttestQueryorg.hibernate.test.legacy.FooBarTesttestOneToOneGeneratororg.hibernate.test.legacy.FooBarTesttestReachabilityorg.hibernate.test.legacy.FooBarTesttestVersionedCollectionsorg.hibernate.test.legacy.FooBarTesttestReturnPropertyComponentRenameorg.hibernate.test.legacy.SQLLoaderTesttestOneToManyLinkTableorg.hibernate.test.onetomany.OneToManyTesttestAutoDetectAliasingorg.hibernate.test.sql.GeneralTesttestScalarStoredProcedureorg.hibernate.test.sql.MySQLTesttestParameterHandlingorg.hibernate.test.sql.MySQLTesttestEntityStoredProcedureorg.hibernate.test.sql.MySQLTest Modifications since last build: (first 50 of 1896)10381addedhonma//trunk/Hibernate3/doc/reference/ja/fop/sazanami-gothic.ttf10381addedhonma//trunk/Hibernate3/doc/reference/ja/fop/sazanami-mincho.ttf10381addedhonma//trunk/Hibernate3/doc/reference/ja/fop/sazanami-gothic.xml10381addedhonma//trunk/Hibernate3/doc/reference/ja/fop/sazanami-mincho.xml10380modifiedhonma//trunk/Hibernate3/doc/reference/ja/fop/userconfig.xmlchange fonts to use sazanami-font10374deleted[EMAIL PROTECTED]//trunk/Hibernate3/doc/reference/ko/fop/Gaeul.ttfDeleted MSFT fonts10374deleted[EMAIL PROTECTED]//trunk/Hibernate3/doc/reference/ko/fop/Gaeul.xmlDeleted MSFT fonts10374deleted[EMAIL PROTECTED]//trunk/Hibernate3/doc/reference/ko/fop/Gulim.xmlDeleted MSFT fonts10374deleted[EMAIL PROTECTED]//trunk/Hibernate3/doc/reference/zh-cn/fop/simsun.ttcDeleted MSFT fonts10374deleted[EMAIL PROTECTED]//trunk/Hibernate3/doc/reference/zh-cn/fop/simhei.ttfDeleted MSFT fonts10374modified[EMAIL PROTECTED]//trunk/Hibernate3/doc/reference/build.xmlDeleted MSFT fonts10374deleted[EMAIL PROTECTED]//trunk/Hibernate3/doc/reference/zh-cn/fop/simhei.xmlDeleted MSFT fonts10374deleted[EMAIL PROTECTED]//trunk/Hibernate3/doc/reference/zh-cn/fop/simsun.xmlDeleted MSF
Re: [hibernate-dev] Connection proxying
You should contribute to http://www.jcp.org/en/jsr/detail?id=305 ;-p Steve Ebersole wrote: Then we need @bad... ;) :) but seriously @deprecate is not only "a going away" marker. From http://java.sun.com/j2se/1.4.2/docs/guide/misc/deprecation/deprecation.html: "Valid reasons for wishing one's users to migrate to the new API include: - the old API is insecure, buggy, or highly inefficient - the old API is going away in a future release - the old API encourages very bad coding practices Not all of these reasons are of equal weight, yet deprecation is a reasonable (though not mandatory) choice in all these cases. Therefore, the use of deprecated APIs can never be made a hard error by default. Also, the deprecation comments need to help the user decide when to move to the new API, and so should briefly mention the technical reasons for deprecation." 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: [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
Re: [hibernate-dev] Connection proxying
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
