Hi, I suspect that the inefficiency is happening because of your use of compound identity -- in some circumstances, OpenJPA can't do bulk deletes when using compound identity currently.
However, I also noticed that your query involves only the primary keys. So, you're not actually doing a bulk delete; you're just deleting the one record that matches those values, correct? If this is the case, then you could use the delete(getReference()) pattern: em.delete(em.getReference(XCap.class, new XCapKey(...)); This will result in a single DELETE statement, since the SELECT can be optimized away when using getReference(). -Patrick On 9/13/07, dboudigue <[EMAIL PROTECTED]> wrote: > > here it is. > > http://www.nabble.com/file/p12669430/XCap.java XCap.java > http://www.nabble.com/file/p12669430/XCapKey.java XCapKey.java > > Patrick Linskey-2 wrote: > > > > Can you post the XCAP class source as well? > > > > Generally-speaking, a select should not always be necessary. > > > > -Patrick > > > > On 9/13/07, dboudigue <[EMAIL PROTECTED]> wrote: > >> > >> Patrick, here are the code and traces. > >> Anyway, an option to skip select in jpl delete or update that would be > >> a > >> nice feature. > >> > >> Didier > >> > >> .... > >> > >> EntityManagerFactory factory = > >> Persistence.createEntityManagerFactory("xcap", props); > >> EntityManager em = factory.createEntityManager(); > >> em.getTransaction().begin(); > >> Query delete = em.createQuery("delete from XCAP x where x.user = :user > >> and > >> x.file = :file and x.auid = :auid"); > >> delete.setParameter("user", user); > >> delete.setParameter("file", file); > >> delete.setParameter("auid", auid); > >> int deleted = delete.executeUpdate(); > >> em.close(); > >> factory.close(); > >> > >> > >> ..... > >> > >> 36 xcap INFO [main] openjpa.Runtime - Starting OpenJPA 1.0.0 > >> 159 xcap INFO [main] openjpa.jdbc.JDBC - Using dictionary class > >> "org.apache.openjpa.jdbc.sql.MySQLDictionary". > >> 329 xcap INFO [main] openjpa.Enhance - Creating subclass and > >> redefining > >> methods for "[class com.alcatel_lucent.jpa.entity.XCap]". This means that > >> your application will be less efficient than it would if you ran the > >> OpenJPA > >> enhancer. > >> 2017 xcap TRACE [main] openjpa.jdbc.SQL - <t 7438914, conn 2016650> > >> executing prepstmnt 21006994 SELECT t0.auid, t0.FILENM, t0.USERNM, > >> t0.CONTENT_TYPE, t0.DOC, t0.DOC_SZ, t0.etag, t0.MODIFIED_DATE FROM XCAP > >> t0 > >> WHERE (t0.USERNM = ? AND t0.FILENM = ? AND t0.auid = ?) [params=(String) > >> didier1, (String) index1, (String) auid1] > >> 2051 xcap TRACE [main] openjpa.jdbc.SQL - <t 7438914, conn 2016650> > >> [33 > >> ms] spent > >> > >> > >> > >> -- > >> View this message in context: > >> http://www.nabble.com/native-sql-tf4428366.html#a12650013 > >> Sent from the OpenJPA Users mailing list archive at Nabble.com. > >> > >> > > > > > > -- > > Patrick Linskey > > 202 669 5907 > > > > > > -- > View this message in context: > http://www.nabble.com/native-sql-tf4428366.html#a12669430 > Sent from the OpenJPA Users mailing list archive at Nabble.com. > > -- Patrick Linskey 202 669 5907
