I'm experiencing a similar problem, and its really disappointing that no one
has replied to this post!
We are getting a SQL timeout exception on DB2 (version 8.x):
DB2 SQL error: SQLCODE: -911, SQLSTATE: 40001, SQLERRMC: 68;
The exception occurs when two processes are run, the first process is a
Hi Fay,
I ran an update this morning, and repackaged, and tested, it the problem
seems to have been resolved.
Updated to revision 702373.
Thanks for your help once again.
Regards,
Enrico
Fay Wang wrote:
>
> Hi Enrico,
> Thank you for your entity classes. I still could not reproduce the
>
Hi Fay,
The SQL is the same for 1.1.0 and 1.2.0.
I'm not sure why its not working on 1.3.0-SNAPSHOT.
Here are those missing classes:
public class TblItmtyp extends BaseEntity {
// Mapped Fields
@Id
@Column(name = "ITMTYP_CDE",nullable=false)
private String itmtypCd
I just tested on 1.2.0 and it works fine there too.
--
View this message in context:
http://n2.nabble.com/Exception-in-SQLBuffer.java-on-OpenJPA-1.3.0-SNAPSHOT-tp1141997p1142020.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
Further to my previous post, here's the SQL that runs for 1.3.0-SNAPSHOT:
3725575 status TRACE [http-8080-3] openjpa.jdbc.SQL - executing prepstmnt 12167706 SELECT t0.ITMDES_ID, t0.DPLODR_NBR,
t0.ITM_CDE, t0.ITM_DES FROM EBSTATUS.TBL_ITMDES t0 ORDER BY t0.DPLODR_NBR
ASC
3725591 status TRAC
Hi,
I'm getting the following exception when this code runs:
public TblItmdes getTrackingItem(String itmCde){
TblItmdes tblItmdes =
getTblItmdesDAO().findTblItmdesByItmCde(itmCde);
tblItmdes.getTblTrklnks(); //<-- lazy load throws exception
return
Hi Mike,
Yeah, I haven't fully tested this, so I guess this change could introduce
other problems.
To answer your question regarding lazy initialization...
I mostly use lazy initialization, but during the process of copying model to
DTO, and back again, an initially null (lazy field) becomes in t
Fixed the compilation problem in my previous post, by running: mvn clean
package
--
View this message in context:
http://n2.nabble.com/Non-dirty-entity-version-field-update-SUPER-URGENT%21%21%21-tp1120307p1133460.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
Further to my previous post, I've altered one line of code in
org.apache.openjpa.kernel.AttachStrategy (line 210):
if ((frmc == null || frmc.isEmpty()) && !nullLoaded) //changed from: if
(frmc == null && !nullLoaded)
...and this seems to fix my problem, but I just tested standalone, not via
my we
I found the problem.
I performed a test using an entity with the least mapped relationships:
TblPdtcde.class:
// Mapped Relationships
@OneToMany(mappedBy="tblPdtcde",fetch = FetchType.LAZY)
private Collection tblScmpdts = new ArrayList();
@Test
public void testMergeUnchangedEntityAPIs()
Hi Michael,
Its a long story, but you can read about it here:
http://n2.nabble.com/%40OneToMany-%40ManyToOne%2C-Bidirectional%2C-Composite-Key-BUG-tc210672.html#a221083
http://n2.nabble.com/%40OneToMany-%40ManyToOne%2C-Bidirectional%2C-Composite-Key-BUG-tc210672.html#a221083
In the mean time,
problem?
> Thanks.
> Catalina
>
> On Fri, Sep 26, 2008 at 12:10 AM, egoosen
> <[EMAIL PROTECTED]>wrote:
>
>>
>> Excellent. Thanks Fay.
>>
>>
>> Fay Wang wrote:
>> >
>> > Thank you, Enrico. I am able to reproduce the problem now. Will
Hi,
I tested again using 1.3.0-SNAPSHOT, and no luck.
Here's the SQL output:
187655 status TRACE [http-8080-1] openjpa.jdbc.SQL - batching prepstmnt 20910753 UPDATE EBSTATUS.TBL_ADR SET VRS_NBR =
? WHERE ADR_ID = ? AND VRS_NBR = ? [params=(int) 26, (int) 1, (int) 25]
187655 status TRACE [
Further to my previous post, I came across this in the OpenJPA documentation
which seemed promising:
1.3.1. Detached State Field
When the detached state field is enabled, the OpenJPA enhancer adds an
additional field to the enhanced version of your class. This field of type
Object. OpenJPA uses
Hi guys,
I have a problem with the version field updating on merge, even though non
of the data has changed.
I found this thread, and posted a message, but no one has responded:
http://n2.nabble.com/how-to-run-an-readonly-query-that-won%27t-update-the-version-field--td837072.html#a837072
http://n
Excellent. Thanks Fay.
Fay Wang wrote:
>
> Thank you, Enrico. I am able to reproduce the problem now. Will post a
> patch to JIRA-731 soon.
>
> -Fay
>
--
View this message in context:
http://n2.nabble.com/OpenJPA-1.2.0-Bug-on-FetchType.EAGER-tp1100274p1120214.html
Sent from the OpenJPA Us
I'm also experiencing this problem, but I am definitely build time enhancing
my classes, and yet the problem persists.
In my case, I'm retrieving the model object, then copying the models values
to a DTO, to pass to a GWT frontend.
After form submit from the frontend, the DTO values get copied t
Hi Fay,
I'm retrieving a TblFndmst entity by its ID (fndCde), then I'm retrieving a
collection of TblAmdctl entities by calling Tblfndmst.getTblAmdctls (this
lazy loads the entities).
TblAmddes are mapped to TblAmdctl with a FetchType.EAGER, so by lazy loading
the TblAmdctls, the TblAmddes entiti
Hi Fay,
Here are the classes:
public class TblAmdctl extends BaseEntity {
// Mapped Fields
@TableGenerator(name="tblAmdctlGenerator",schema="EBSTATUS",table="TBL_KEYGEN",pkColumnName="PRIMARY_KEY_COLUMN"
,valueColumnName="LAST_USED_ID",pkColumnValue="TBL_AMDCTL_ID",allocationSize
Hi Fay,
I think it would be difficult to recreate this bug in a standalone test case
like you have created.
As mentioned previously, this bug only surfaces on the second find.
Perhaps if you modify your test case by reusing the em for the create and
the find, it could reproduce the bug?
Regards
Hi Kevin,
Sorry I don't have access to the JIRA System.
Kind regards,
Enrico
Kevin Sutter wrote:
>
> Cool (and not so cool). This indicates that we have a potential problem
> with our sql query caching support. Do you have access to our JIRA
> system?
> If so, please go ahead and open a JIR
Hi Kevin,
I added that property and it fixed the problem.
Kind regards,
Enrico
Kevin Sutter wrote:
>
> Egoosen2,
> One new feature that went into 1.2.0 was the ability to cache some of the
> generated sql on common queries. Previous to this change, every query or
> findBy operation required
I'm experiencing a strange bug in 1.2.0, on an eager loaded one to many
relationship.
The first time I run the code, openJPA retrieves the parent entity and eager
fetches the CORRECT child entities.
The second time around, it fetches the parent entity and fetches the
INCORRECT child entities (spec
data.
Georgi Naplatanov wrote:
>
> Hello, egoosen.
>
> Do you can prepare a test case which reproduce this problem ?
>
> In case you can do this, please open an issue report on Jira.
>
> I had similar problem, but can not localize the problem and create a
> t
I'm experiencing a cache problem with the current version of OpenJPA (1.2.0),
and previous versions.
I've setup the cache as follows in persistence.xml:
We're using Spring JpaDaoSupport.
The org.springframework.orm.jpa.LocalEntityManagerFactoryBean is Spring
loaded.
The problem is that my que
Hi Tim,
I set the "updateable=false" property, but that didn't have any effect.
Here it is:
// Mapped Fields
@TableGenerator(name="tblPdtcdeGenerator",schema="EBSTATUS",table="TBL_KEYGEN",pkColumnName="PRIMARY_KEY_COLUMN"
,valueColumnName="LAST_USED_ID",pkColumnValue="TBL_PDTCDE_I
I've found a solution to my problem...
tblScmpdt.setTblPdtcde(null); //immutable, don't merge
The foreign key is still set (tblScmpdt.pdtcdeId), so by setting the related
entity to null, it prevents OpenJPA from trying to merge it.
--
View this message in context:
http://n2.nabble.com/How-to-pr
I'm using OpenJPA with GWT, and therefore I'm copying my model object to a
GWT friendly DTO, before passing it to the frontend (and visa versa when
returning from the frontend).
When I check my debug output, I notice that there are update statements for
entities that are supposed to be immutable
Just want to update this post in case someone else stubbles on the same
problems that we did.
My colleague (who's a OpenJPA Ninja) rewrote our DAO's to overcome the
problems I mentioned before.
This included adding the OpenJPA specific annotation @ForeignKey to
@ManyToOne relationships, cos otherw
29 matches
Mail list logo
