Re: COPY using Hibernate

Thank you very much for you replies, I'll try these solutions as well and will get back to you.

The other way I am trying is the pg/plsql stored procedure. As per the requirement, I have to insert around a million integers in a table having just one column. I am not aware of how to use "COPY FROM STDIN" using pg/plsql. I'll pass these integers as array to stored procedure. I want to avoid dependency of file, otherwise it could have been done easily using "COPY FROM file". Looking for more information on internet to solve the issue. If anybody aware of the way, please help me.

Thanks,
Vaibhav.

________________________________
From: Steve Waldman <swaldman(at)mchange(dot)com>
To: Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>
Cc: Dave Cramer <pg(at)fastcrypt(dot)com>; Vaibhav Patil <infovaibhav(at)yahoo(dot)com>; "pgsql-jdbc(at)postgresql(dot)org" <pgsql-jdbc(at)postgresql(dot)org>
Sent: Fri, 15 January, 2010 7:56:21 PM
Subject: Re: [JDBC] COPY using Hibernate

you can just check out the inner Connection with c3p0's reflective API, if you want. the preachiness is a speedbump, but nothing prevents you from returning RAW_CONNECTION_OBJECT. just be sure that when you're done, the you've not left the state of the Connection modified, cuz that can lead to subtle misbehavior.

~oo~
Steve Waldman
swaldman(at)mchange(dot)com

On Jan 15, 2010, at 7:59 AM, Craig Ringer <craig(at)postnewspapers(dot)com(dot)au> wrote:

> On 15/01/2010 8:00 PM, Dave Cramer wrote:
>> Hi Vaibhav
>>
>> C3p0 provides a mechanism to get at the underlying connection and
>> statement. search for c3P0 underlying connection
>
> According to the C3P0 docs:
>
> "JDBC drivers sometimes define vendor-specific, non-standard API on Connection and Statement implementations. C3P0 wraps these Objects behind a proxies, so you cannot cast C3P0-returned Connections or Statements to the vendor-specific implementation classes. C3P0 does not provide any means of accessing the raw Connections and Statements directly, because C3P0 needs to keep track of Statements and ResultSets created in order to prevent resource leaks and pool corruption."
>
> ... so, you can't just get the connection from your Hibernate Session and use that. Instead, you have to do it reflectively via C3P0 methods:
>
> "C3P0 does provide an API that allows you to invoke non-standard methods
> reflectively on an underlying Connection. To use it, first cast the
> returned Connection to a C3P0ProxyConnection. Then call the method
> rawConnectionOperation, supplying the java.lang.reflect.Method object
> for the non-standard method you wish to call as an argument. The Method
> you supply will be invoked on the target you provide on the second
> argument (null for static methods), and using the arguments you supply
> in the third argument to that function. For the target, and for any of
> the method arguments, you can supply the special token
> C3P0ProxyConnection.RAW_CONNECTION, which will be replaced with the
> underlying vendor-specific Connection object before the Method is invoked."
>
> See:
> http://www.mchange.com/projects/c3p0/index.html#raw_connection_ops
>
>
> Permit me to say "argh!". It's highly frustrating that you can't just "check out" a connection, unwrapping it and taking responsibility for any statements and result sets you create while it's unwrapped.
>
> ( C3P0's documentation is really preachy about this, and likes to
> explain to you how you shouldn't want to do "legacy" things like
> that since it breaks "database independence" which is apparently
> something it's unthinkable not to care about for your particular
> app ... sigh. )
>
> In my J2SE app I only need one connection for the app - and in fact it's strongly preferable to limit the app to one connection. I also needed direct access to that connection to use listen/notify via PgConnection. Hibernate wants you to use a connection pool, and jealously guards the connections it obtains via the pool - in fact, if you're using Hibernate via JPA2 you can't access the underlying JDBC connection *at* *all*.
>
> Thankfully Hibernate provides a clean and simple abstraction for its access to connection pools, so I landed up writing my own SingleConnectionProvider to give Hibernate its "pool" of one connection. The provider blocks on any getConnection(...) requests issued while the connection is checked out to someone else, so I can just check the connection out of the pool directly if I want to do PostgreSQL-specific things with it ( like using listen/notify or COPY ) and use Hibernate the rest of the time. It works great. If it'd be of any use to you, let me know.
>
> --
> Craig Ringer
>
> --Sent via pgsql-jdbc mailing list (pgsql-jdbc(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-jdbc

The INTERNET now has a personality. YOURS! See your Yahoo! Homepage. http://in.yahoo.com/