Hi Will,
Accessing the Connection directly should also be a possibility.  Not sure
about the exceptions you are getting though.  The IllegalStateException
sounds like you might be requesting a Connection when a Connection doesn't
exist.  What ConnectionRetainMode value are you using?  Maybe you need to
hold onto your Connections longer (ie. transaction scoped) to satisfy this
extra processing you are looking to do.

The other path you describe sounds convoluted when creating a new EM just
to get access to a Connection.  It looks like OpenJPA is getting confused
going through this path and is accidentally calling into the synchronize
mappings processing.

If you could help isolate the issues with simple junit test cases, it would
be much easier to debug.

Good luck,
Kevin

On Mon, Jan 28, 2013 at 9:49 AM, Will Hoover <java.whoo...@gmail.com> wrote:

> Thanks for the suggestions Kevin! I'd like to stay clear of listeners if I
> can so I can keep it localized to the handful of use cases where I actually
> need it :/
>
> I'm not sure if this is the best solution or not, but I seem to be running
> out of practical solutions that will keep metadata isolated. I figured that
> in this case I'm already using a native query. So, why not just capture the
> connection from the entity manager and create the native statement that
> will
> allow access to the metadata. The only problem is the
> entityManager.unwrap(java.sql.Connection.class) seems to be unpredictable.
> Sometimes I receive "java.lang.IllegalStateException: No transactional
> EntityManager available" and
>
> entityManager.getEntityManagerFactory().createEntityManager().unwrap(java.sq
> l.Connection.class) likes to call "synchronizeMappings" in
> JDBCBrokerFactory#newBrokerImpl(String user, String pass) even though the
> OpenJPA documentation (version 2.2.1) indicates that the lack of
> "openjpa.jdbc.SynchronizeMappings" will prevent such a call. Maybe I'm
> missing something here?
>
> -----Original Message-----
> From: Kevin Sutter [mailto:kwsut...@gmail.com]
> Sent: Thursday, January 24, 2013 9:34 AM
> To: users@openjpa.apache.org
> Subject: Re: OpenJPA + Native Query = Meta Data
>
> Not that I am aware of...  Of course, OpenJPA has access to and utilizes
> the
> metadata while processing the result set, but I don't see a means of
> providing that metadata back to the application.  Since OpenJPA is
> open-source, we always welcome new feature submissions...  :-)
>
> One alternative that might work for you is to tie into OpenJPA's JDBC
> Listeners [1].  If you tied into the post execute statement listener, you
> could get access to the jdbc-related artifacts and do your own parsing of
> the information.  Maybe not quite as easy as the eclipselink feature, but
> would that provide the metadata you are looking for?
>
> Kevin
>
> [1]
>
> http://people.apache.org/~mikedd/nightly.builds/apache-openjpa-2.3.0-SNAPSHO
> T/docs/docbook/manual.html#openjpa.jdbc.JDBCListeners<http://people.apache.org/%7Emikedd/nightly.builds/apache-openjpa-2.3.0-SNAPSHO%0AT/docs/docbook/manual.html#openjpa.jdbc.JDBCListeners>
>
> On Tue, Jan 22, 2013 at 2:11 PM, Will Hoover <java.whoo...@gmail.com>
> wrote:
>
> > Is there any feature in OpenJPA that will allow capture of a queries
> > metadata (similar to "eclipselink.result-type"="Map")?
> >
> >
> >
> > I'm trying to capture a rowid from a native query update call.
> >
> >
> >
> >
> >
> >
>
>

Reply via email to