openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Vorburger" <>
Subject RE: Mapping a temporary table
Date Wed, 14 Jan 2009 19:46:30 GMT
Hi Pinaki!

The idea to use a custom DBDictionary for "SQL interception and
customization" is great; indeed it offers a lot of useful methods that
could give one all sorts of ideas... ;)  (E.g. 1. add arbitrary SQL,  2.
calling stored procedures transparently,  3. replace bits of SQL; I'm
copy/pasting a few methods which look very interesting below for other
readers benefits).

However, for the specific use case we face there is a minor hick-up,
which I believe is similar to what 'Konstantin' means in the post you
referenced when he says "...and through EntityManager interface. The
latter is needed because some filters may be dynamic - e.g. I want to
switch off DELETE_TS filtering when I need to work with "deleted"
instances. ": In our use case as well, what I would implement inside an
@Override getFullName() is... User/EntityManager/Connection specific
(details: need to append some kind of semi-temporary session ID to a
normal table name). 

I was initially hoping that I could, given an EM, use
tDBDictionary(dbdictionary) to set an EntityManager/Connection specific
DBDictionary, but that leads to an IllegalStateException; it's too late
/ there can only be one per EMF, not an individual one per EM,
presumably, right?

Any suggestions on how to address this?  May be I'm dumb, but the only
solution I can think of right now was to may be have the one and only
instance of some FunkyDBDictionary (configured at startup through usual
openjpa.jdbc.DBDictionary property) use a ThreadLocal Map for (re)name
mapping, to make it EntityManager/Connection specific... or do you see
any cleaner way to do this?


public String getFullName(Table table, boolean logical) {

protected PreparedStatement prepareStatement(Connection conn, String

public SQLBuffer toOperation(String op, SQLBuffer selects,
    SQLBuffer from, SQLBuffer where, SQLBuffer group, SQLBuffer having,
    SQLBuffer order, boolean distinct, long start, long end,
    String forUpdateClause) {

public SQLBuffer toSelect(Select sel, boolean forUpdate,
    JDBCFetchConfiguration fetch) {

public SQLBuffer toSelect(SQLBuffer selects, JDBCFetchConfiguration
    SQLBuffer from, SQLBuffer where, SQLBuffer group,
    SQLBuffer having, SQLBuffer order,
    boolean distinct, boolean forUpdate, long start, long end) {

public SQLBuffer toSelectCount(Select sel) {

public SQLBuffer toSQL92Join(Join join, boolean forUpdate, boolean
first) {

public SQLBuffer toTraditionalJoin(Join join) { 

public SQLBuffer toDelete(ClassMapping mapping, Select sel, 
    Object[] params) {

public SQLBuffer toUpdate(ClassMapping mapping, Select sel,
    JDBCStore store, Object[] params, Map updates) {

-----Original Message-----
From: Pinaki Poddar [] 
Sent: Tuesday, January 13, 2009 10:28 PM
Subject: RE: Mapping a temporary table

  Recently, some thing similar (actually more complex manipulation of
SQL) was attempted to filter out soft-deleted records.
  Check out the thread [1].

View this message in context:
Sent from the OpenJPA Users mailing list archive at


 This email and any files transmitted with it are CONFIDENTIAL and intended
  solely for the use of the individual or entity to which they are addressed.
 Any unauthorized copying, disclosure, or distribution of the material within
  this email is strictly forbidden.
 Any views or opinions presented within this e-mail are solely those of the
  author and do not necessarily represent those of Odyssey Financial
Technologies SA unless otherwise specifically stated.
 An electronic message is not binding on its sender. Any message referring to
  a binding engagement must be confirmed in writing and duly signed.
 If you have received this email in error, please notify the sender immediately
  and delete the original.

View raw message