RE: JIRA / svn integration
Maybe just latency? The JIRA plugin periodically scans, I think. Maybe you just checked at a bad time? -Patrick -- Patrick Linskey BEA Systems, Inc. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. > -Original Message- > From: Kevin Sutter [mailto:[EMAIL PROTECTED] > Sent: Wednesday, February 07, 2007 3:13 PM > To: open-jpa-dev@incubator.apache.org > Subject: Re: JIRA / svn integration > > Yes, this is nice. Another good reason to use the JIRA > report number in > your commit message. The strange thing is that this doesn't > always seem to > work. Every once in a while, the svn commit changes don't > get documented in > the JIRA report, even when the commit message indicates the > JIRA report. > Not sure what causes the random anomaly... Does the > committer have to be > the assignee of the JIRA report? Network glitch with no > retry logic? Any > other ideas? > > Kevin > > On 2/6/07, Patrick Linskey <[EMAIL PROTECTED]> wrote: > > > > Hi, > > > > I just discovered that Apache's JIRA install runs the JIRA / svn > > integration plugin. Take a look at the svn information towards the > > bottom of https://issues.apache.org/jira/browse/OPENJPA-119 for an > > example, and the "Subversion Commits" tab on the > browse-project page: > > https://issues.apache.org/jira/secure/BrowseProject.jspa > > > > Neat! > > > > -Patrick > > > > -- > > Patrick Linskey > > BEA Systems, Inc. > > > > > __ > _ > > Notice: This email message, together with any attachments, > may contain > > information of BEA Systems, Inc., its subsidiaries and > affiliated > > entities, that may be confidential, proprietary, > copyrighted and/or > > legally privileged, and is intended solely for the use of > the individual > > or entity named in this message. If you are not the > intended recipient, > > and have received this message in error, please immediately > return this > > by email and then delete it. > > >
RE: Cache with two ConnectionFactories?
There are a lot of things that you could do. The simplest, and least cache-effective, would be to have two different EMFs that each have their own caches. These caches could be linked together (using the sjvm remote commit provider), so that data would stay consistent, but otherwise, this would be like using different databases. If you can access the same data via both data sources, the other option would be to create your own data source that uses a ThreadLocal or something to decide which underlying data source to use, and tell OpenJPA to use that data source. Then, depending on the use case, you could select a different data source. Or, if the only thing that you need is different connection credentials when logging in, you could use a single data source and call EMF.createEntityManager(Map) with openjpa.ConnectionUserName and openjpa.ConnectionPassword key-value pairs in the map. Hope that helps, -Patrick -- Patrick Linskey BEA Systems, Inc. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. > -Original Message- > From: Don Brady [mailto:[EMAIL PROTECTED] > Sent: Wednesday, February 07, 2007 4:59 PM > To: open-jpa-dev@incubator.apache.org > Subject: Cache with two ConnectionFactories? > > I could not figure this out in reading the OpenJPA documentation. > > We have just the one database and set of tables, but we need > to have two > separate Connection Pools to the same database in order to have two > different userid's. > > (We want to set the priorities on the database differently > for access by > the two different usernames). > > One is to be used for updates and short queries, and the other for > queries expected to give large result sets. > > In these circumstances, is it possible to use the Data Cache and the > Query Cache? > > I am worried that if a new entity / data row is created in the Data > Cache under one userid/pool/connectionFactory, it will not show up in > the Query Cache for the other userid/pool/connectionFactory > if a query > is done. > > Thanks and if this is off-topic please let me know. > > Maybe the thing to do would be to have a cache enabled for the > userid/pool/connectionFactory used for short queries and > updates, but no > cache for the userid/pool/connectionFactory? > > Don >
[jira] Created: (OPENJPA-136) CommonJ WorkManager integration
CommonJ WorkManager integration --- Key: OPENJPA-136 URL: https://issues.apache.org/jira/browse/OPENJPA-136 Project: OpenJPA Issue Type: New Feature Components: kernel Reporter: Patrick Linskey We should use the CommonJ WorkManager APIs instead of directly creating threads ourselves. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-128) Automatic cache pre-fill on server start
[ https://issues.apache.org/jira/browse/OPENJPA-128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12471195 ] Patrick Linskey commented on OPENJPA-128: - We could also do this by specifying named queries in the DataCacheWarmUp string, and those named queries could have query hints to control ranging. > Automatic cache pre-fill on server start > > > Key: OPENJPA-128 > URL: https://issues.apache.org/jira/browse/OPENJPA-128 > Project: OpenJPA > Issue Type: New Feature >Reporter: Patrick Linskey > > It'd be nice to have some means to automatically pre-fill the cache when a > node starts up, either by copying from a different node or from a serialized > image on disk, or by issuing some pre-specified queries. I really like the > idea of just letting the user specify something like so: > \"SELECT p FROM Product p ORDER BY p.salesRank\""/> > Although in that last example, we'd really want some way to specify a bit > more detail about which pages of the data to use, as you would in > single-string JDOQL. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OPENJPA-135) join fetch not returning duplicate references which not conforming to ejb3.0 spec
join fetch not returning duplicate references which not conforming to ejb3.0 spec - Key: OPENJPA-135 URL: https://issues.apache.org/jira/browse/OPENJPA-135 Project: OpenJPA Issue Type: Bug Components: jpa Reporter: Catalina Wei In the description in EJB 3.0 JPA spec, section 4.4.5.3, the following query example SELECT d FROM Department d LEFT JOIN FETCH d.employees WHERE d.deptno = 1 The spec says this query returns 5 references to the department 1 entity if department 1 has 5 employees. The same query running with openjpa code, it returns only 1 reference to department 1 entity. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OPENJPA-134) Extra unneeded SQL joins for OneToMany relationship with fetch type EAGER
Extra unneeded SQL joins for OneToMany relationship with fetch type EAGER - Key: OPENJPA-134 URL: https://issues.apache.org/jira/browse/OPENJPA-134 Project: OpenJPA Issue Type: Bug Components: sql Reporter: Catalina Wei Running JPAConfiguration default setting for EagerFetchMode (FetchModeValue.EAGER_PARALLEL), the SQL generated is sub-optimal. Consider the following entities: lineitems( OneToMany ) Order <===> OrderItem order ( ManyToOne ) Case 1: why not combining 2 SQL to 1 SQL ? = Order.lineitmes(EAGER): OrderItem.order(LAZY): Executing query: select o from Order o 2173 demo TRACE [main] openjpa.jdbc.SQL - executing prepstmnt 1299336562 SELECT t0.oid, t0.version, t0.amount, t0.customer_countryCode, t0.customer_id, t0.delivered, t0.shipaddr FROM Order t0 2213 demo TRACE [main] openjpa.jdbc.SQL - [40 ms] spent 2223 demo TRACE [main] openjpa.jdbc.SQL - executing prepstmnt 1406424020 SELECT t0.oid, t1.lid, t1.version, t1.cost, t1.order_oid, t1.part_partno, t1.quantity FROM Order t0 INNER JOIN OrderItem t1 ON t0.oid = t1.order_oid ORDER BY t0.oid ASC Case 2: extra unneeded LEFT OUTER JOIN, if eliminated, the selection aliase t2 should change to t1: = Order.lineitmes(EAGER): OrderItem.order(LAZY): Executing query: select o from Order o left join fetch o.lineitems 2403 demo TRACE [main] openjpa.jdbc.SQL - executing prepstmnt 1500797300 SELECT t0.oid, t0.version, t0.amount, t0.customer_countryCode, t0.customer_id, t0.delivered, t0.shipaddr, t2.order_oid, t2.lid, t2.version, t2.cost, t2.part_partno, t2.quantity FROM Order t0 LEFT OUTER JOIN OrderItem t1 ON t0.oid = t1.order_oid LEFT OUTER JOIN OrderItem t2 ON t0.oid = t2.order_oid ORDER BY t2.order_oid ASC Case 3: why not generating 1 SQL ? == Order.lineitmes(EAGER): OrderItem.order(EAGER): Executing query: select o from Order o 2343 demo TRACE [main] openjpa.jdbc.SQL - executing prepstmnt 384833264 SELECT t0.oid, t0.version, t0.amount, t0.customer_countryCode, t0.customer_id, t0.delivered, t0.shipaddr FROM Order t0 2383 demo TRACE [main] openjpa.jdbc.SQL - [40 ms] spent 2393 demo TRACE [main] openjpa.jdbc.SQL - executing prepstmnt 1722705582 SELECT t0.oid, t1.lid, t1.version, t1.cost, t2.oid, t2.version, t2.amount, t2.customer_countryCode, t2.customer_id, t2.delivered, t2.shipaddr, t1.part_partno, t1.quantity FROM Order t0 INNER JOIN OrderItem t1 ON t0.oid = t1.order_oid LEFT OUTER JOIN Order t2 ON t1.order_oid = t2.oid ORDER BY t0.oid ASC 2393 demo TRACE [main] openjpa.jdbc.SQL - [0 ms] spent 3134 demo TRACE [main] openjpa.jdbc.SQL - executing prepstmnt 950548648 SELECT t0.lid, t0.version, t0.cost, t1.oid, t1.version, t1.amount, t1.customer_countryCode, t1.customer_id, t1.delivered, t1.shipaddr, t0.part_partno, t0.quantity FROM OrderItem t0 LEFT OUTER JOIN Order t1 ON t0.order_oid = t1.oid WHERE t0.order_oid = ? [params=(int) 88] 3134 demo TRACE [main] openjpa.jdbc.SQL - [0 ms] spent Case 4: duplicate selections and redundant joins == Order.lineitmes(EAGER): OrderItem.order(EAGER): Executing query: select o from Order o left join fetch o.lineitems 2273 demo TRACE [main] openjpa.jdbc.SQL - executing prepstmnt 1565154634 SELECT t0.oid, t0.version, t0.amount, t0.customer_countryCode, t0.customer_id, t0.delivered, t0.shipaddr, t2.order_oid, t2.lid, t2.version, t2.cost, t3.oid, t3.version, t3.amount, t3.customer_countryCode, t3.customer_id, t3.delivered, t3.shipaddr, t2.part_partno, t2.quantity FROM Order t0 LEFT OUTER JOIN OrderItem t1 ON t0.oid = t1.order_oid LEFT OUTER JOIN OrderItem t2 ON t0.oid = t2.order_oid LEFT OUTER JOIN Order t3 ON t2.order_oid = t3.oid ORDER BY t2.order_oid ASC -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Cache with two ConnectionFactories?
I could not figure this out in reading the OpenJPA documentation. We have just the one database and set of tables, but we need to have two separate Connection Pools to the same database in order to have two different userid's. (We want to set the priorities on the database differently for access by the two different usernames). One is to be used for updates and short queries, and the other for queries expected to give large result sets. In these circumstances, is it possible to use the Data Cache and the Query Cache? I am worried that if a new entity / data row is created in the Data Cache under one userid/pool/connectionFactory, it will not show up in the Query Cache for the other userid/pool/connectionFactory if a query is done. Thanks and if this is off-topic please let me know. Maybe the thing to do would be to have a cache enabled for the userid/pool/connectionFactory used for short queries and updates, but no cache for the userid/pool/connectionFactory? Don
Re: JIRA / svn integration
Yes, this is nice. Another good reason to use the JIRA report number in your commit message. The strange thing is that this doesn't always seem to work. Every once in a while, the svn commit changes don't get documented in the JIRA report, even when the commit message indicates the JIRA report. Not sure what causes the random anomaly... Does the committer have to be the assignee of the JIRA report? Network glitch with no retry logic? Any other ideas? Kevin On 2/6/07, Patrick Linskey <[EMAIL PROTECTED]> wrote: Hi, I just discovered that Apache's JIRA install runs the JIRA / svn integration plugin. Take a look at the svn information towards the bottom of https://issues.apache.org/jira/browse/OPENJPA-119 for an example, and the "Subversion Commits" tab on the browse-project page: https://issues.apache.org/jira/secure/BrowseProject.jspa Neat! -Patrick -- Patrick Linskey BEA Systems, Inc. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
[jira] Created: (OPENJPA-133) Can't find non-public callback methods with superclass or interface parameters
Can't find non-public callback methods with superclass or interface parameters
--
Key: OPENJPA-133
URL: https://issues.apache.org/jira/browse/OPENJPA-133
Project: OpenJPA
Issue Type: Bug
Components: jpa
Reporter: Kevin Sutter
Assigned To: Kevin Sutter
Using xml to define my listener callback methods (doesn't make any difference
whether we're using MappedSuperclass or Entity):
My Entity heirarchy is defined as follows:
public interface CallbackMarker { }
@MappedSuperclass
public class CallbackSuperclass implements CallbackMarker { .. }
@Entity
public class CallbackEntity extends CallbackSuperclass { .. }
My listener method is defined as follows:
public class CallbackListener {
:
private void postPersistXML(CallbackMarker cbm) {
System.out.println("PostPersist (ListenerXML) on CallbackMarker: " +
cbm);
((CallbackEntity)cbm).postSuccessful = true;
}
:
}
I'm probably clouding the issue with all of these details, but the real problem
is that we're not properly finding the postPersistXML(CallbackMarker cbm)
method. When I run the example, I am getting the following exception. The
original
call stack is huge, so I will just include the "caused by":
Caused by: java.lang.NoSuchMethodException:
com.ibm.ws.persistence.tests.callbacks.CallbackListener.postPersistXML(com.ibm.ws.persistence.tests.callbacks.CallbackSuperclass)
at java.lang.Class.throwNoSuchMethodException(Class.java:271)
at java.lang.Class.getMethod(Class.java:748)
at
org.apache.openjpa.event.MethodLifecycleCallbacks.getMethod(MethodLifecycleCallbacks.java:123)
Digging through the problem, I am finding that we're not properly reflecting on
the Class to find the appropriate Method. First, we
do a getMethods(), which only returns the public methods. Of course, nothing
matches up, so we end up in the catch {} block. Here,
we attempt a getDeclaredMethod() passing in the specific type for the argument.
This doesn't work in this case since the specific
type (CallbackSuperclass) isn't on the Method signature (the interface
CallbackMarker is). Also, calling getDeclaredMethod only looks in the specific
Class and does not go up the heirarchy (like getMethods() does). So, we have a
couple of problems with this
method.
My proposed change is to use the getDeclaredMethods() invocation and manually
go up the heirarchy (if necessary). If we go all the way up the tree without
finding the method, then we throw the exception. This seems to clear up the
processing and makes the code
more readable (no try/catch is required). You could argue that this approach
might take more processing since we might have to get the Superclass and make
additional getDeclaredMethods() invocations. But, my guess is that most of the
methods being requested will be on the base class and no additional invocations
will be necessary.
FYI, this problem only exists with the XML configuration since the annotated
version doesn't do this parameter checking. Annotated callback methods just
register the method and assume that it will work. If it doesn't, then we get a
runtime exception with IllegalArgumentException. Whether we should do this
type checking for the annotated callbacks is a topic for a separate JIRA
report...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (OPENJPA-132) java.lang.NoSuchMethodError for entity with ID of type java.sql.Date
java.lang.NoSuchMethodError for entity with ID of type java.sql.Date
Key: OPENJPA-132
URL: https://issues.apache.org/jira/browse/OPENJPA-132
Project: OpenJPA
Issue Type: Bug
Components: kernel
Reporter: Michael Dick
Opening JIRA report to track the following problem (posted to development forum
http://www.nabble.com/Exception-when-using-java.sql.Date-as-an-id-tf3189597.html)
I'm getting the following exception when I try to fetch an entity with a
java.sql.Date as the id :
java.lang.NoSuchMethodError:
org.apache.openjpa.util.DateId.getId()Ljava/sql/Date;
at mikedd.entities.SqlDatePK.pcCopyKeyFieldsFromObjectId (SqlDatePK.java)
at mikedd.entities.SqlDatePK.pcNewInstance(SqlDatePK.java)
at org.apache.openjpa.enhance.PCRegistry.newInstance(PCRegistry.java:118)
at org.apache.openjpa.kernel.StateManagerImpl.initialize
(StateManagerImpl.java:247)
at
org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initializeState(JDBCStoreManager.java:327)
at
org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initialize(JDBCStoreManager.java:252)
at
org.apache.openjpa.kernel.DelegatingStoreManager.initialize(DelegatingStoreManager.java:108)
at
org.apache.openjpa.kernel.ROPStoreManager.initialize(ROPStoreManager.java:54)
at org.apache.openjpa.kernel.BrokerImpl.initialize (BrokerImpl.java:868)
at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:826)
at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:743)
at org.apache.openjpa.kernel.DelegatingBroker.find
(DelegatingBroker.java:169)
at
org.apache.openjpa.persistence.EntityManagerImpl.find(EntityManagerImpl.java:346)
at mikedd.tests.TestSqlDateId.testFindAfterClear(TestSqlDateId.java:25)
at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke (Method.java:585)
at junit.framework.TestCase.runTest(TestCase.java:154)
. . .
It's coming from the generated bytecode which expects there to be a getId
method that returns the same type of the Id, however java.sql.Date is using the
same ID class as java.util.Date. Do we need a separate class for java.sql.Date?
Responses from Patrick and Craig follow. The consensus so far is to provide ID
separate classes for java.sql.Date and java.util.Date.
It looks like we either need a separate type for java.sql.Date (and
presumably java.sql.Timestamp), or we need to change the logic to accept
a getId() method that returns a type that is assignable from the id
field's type.
-Patrick
It's probably cleaner if we have separate classes for the different
types. That is, have the getId method in the new
org.apache.openjpa.util.SQLDateId return the proper type
(java.sql.Date). After all, java.sql.{Date, Time, Timestamp} are not
really the same as java.util.Date.
-Craig
FTR, I think that I prefer separate classes as well; it's clearer, and
avoids any ambiguity with other subclasses in the future.
-Patrick
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
RE: Exception when using java.sql.Date as an id
FTR, I think that I prefer separate classes as well; it's clearer, and
avoids any ambiguity with other subclasses in the future.
-Patrick
--
Patrick Linskey
BEA Systems, Inc.
___
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.
> -Original Message-
> From: Michael Dick [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, February 07, 2007 2:34 PM
> To: open-jpa-dev@incubator.apache.org
> Subject: Re: Exception when using java.sql.Date as an id
>
> Thanks, I'll open a JIRA report and take a crack at a solution.
>
> On 2/7/07, Craig L Russell <[EMAIL PROTECTED] > wrote:
> >
> >
> > On Feb 7, 2007, at 1:55 PM, Patrick Linskey wrote:
> >
> > >> It's coming from the generated bytecode which expects there
> > >> to be a getId
> > >> method that returns the same type of the Id, however
> > >> java.sql.Date is using
> > >> the same ID class as java.util.Date. Do we need a
> separate class for
> > >> java.sql.Date ?
> > >
> > > It looks like we either need a separate type for
> java.sql.Date (and
> > > presumably java.sql.Timestamp), or we need to change the logic to
> > > accept
> > > a getId() method that returns a type that is assignable
> from the id
> > > field's type.
> >
> > It's probably cleaner if we have separate classes for the different
> > types. That is, have the getId method in the new
> > org.apache.openjpa.util.SQLDateId return the proper type
> > (java.sql.Date). After all, java.sql.{Date, Time, Timestamp} are not
> > really the same as java.util.Date.
> >
> > Craig
> > >
> > > -Patrick
> > >
> > > --
> > > Patrick Linskey
> > > BEA Systems, Inc.
> > >
> > >
> __
> > > _
> > > Notice: This email message, together with any attachments, may
> > > contain
> > > information of BEA Systems, Inc., its subsidiaries and
> > > affiliated
> > > entities, that may be confidential, proprietary, copyrighted
> > > and/or
> > > legally privileged, and is intended solely for the use of the
> > > individual
> > > or entity named in this message. If you are not the intended
> > > recipient,
> > > and have received this message in error, please immediately return
> > > this
> > > by email and then delete it.
> > >
> > >> -Original Message-
> > >> From: Michael Dick [mailto: [EMAIL PROTECTED]
> > >> Sent: Wednesday, February 07, 2007 12:57 PM
> > >> To: open-jpa-dev@incubator.apache.org
> > >> Subject: Exception when using java.sql.Date as an id
> > >>
> > >> Hi,
> > >>
> > >> I'm getting the following exception when I try to fetch an
> > >> entity with a
> > >> java.sql.Date as the id :
> > >>
> > >> java.lang.NoSuchMethodError: org.apache.openjpa.util.DateId.getId
> > >> ()Ljava/sql/Date;
> > >> at mikedd.entities.SqlDatePK.pcCopyKeyFieldsFromObjectId
> > >> (SqlDatePK.java
> > >> )
> > >> at mikedd.entities.SqlDatePK.pcNewInstance(SqlDatePK.java)
> > >> at
> > >> org.apache.openjpa.enhance.PCRegistry.newInstance(PCRegistry.java
> > >> :118)
> > >> at org.apache.openjpa.kernel.StateManagerImpl.initialize (
> > >> StateManagerImpl.java:247)
> > >> at
> > >> org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initializeState(
> > >> JDBCStoreManager.java:327)
> > >> at
> org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initialize(
> > >> JDBCStoreManager.java:252)
> > >> at
> org.apache.openjpa.kernel.DelegatingStoreManager.initialize (
> > >> DelegatingStoreManager.java:108)
> > >> at org.apache.openjpa.kernel.ROPStoreManager.initialize(
> > >> ROPStoreManager.java:54)
> > >> at org.apache.openjpa.kernel.BrokerImpl.initialize
> > >> (BrokerImpl.java:868)
> > >> at
> org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:826)
> > >> at
> org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:743)
> > >> at org.apache.openjpa.kernel.DelegatingBroker.find (
> > >> DelegatingBroker.java:169)
> > >> at org.apache.openjpa.persistence.EntityManagerImpl.find(
> > >> EntityManagerImpl.java:346)
> > >> at
> > >> mikedd.tests.TestSqlDateId.testFindAfterClear
> (TestSqlDateId.java:25)
> > >> at sun.reflect.NativeMethodAccessorImpl.invoke0
> (Native Method)
> > >> at sun.reflect.NativeMethodAccessorImpl.invoke(
> > >> NativeMethodAccessorImpl.java:39)
> > >> at sun.reflect.DelegatingMethodAccessorImpl.invoke(
> > >> DelegatingMethodAccessorImpl.java:25)
> > >> at java.lang.reflect.Method.invoke (Method.java:585)
> > >> at junit.framework.TestCase.runTest(TestCase.java :154)
> >
Re: Exception when using java.sql.Date as an id
Thanks, I'll open a JIRA report and take a crack at a solution.
On 2/7/07, Craig L Russell <[EMAIL PROTECTED] > wrote:
On Feb 7, 2007, at 1:55 PM, Patrick Linskey wrote:
>> It's coming from the generated bytecode which expects there
>> to be a getId
>> method that returns the same type of the Id, however
>> java.sql.Date is using
>> the same ID class as java.util.Date. Do we need a separate class for
>> java.sql.Date ?
>
> It looks like we either need a separate type for java.sql.Date (and
> presumably java.sql.Timestamp), or we need to change the logic to
> accept
> a getId() method that returns a type that is assignable from the id
> field's type.
It's probably cleaner if we have separate classes for the different
types. That is, have the getId method in the new
org.apache.openjpa.util.SQLDateId return the proper type
(java.sql.Date). After all, java.sql.{Date, Time, Timestamp} are not
really the same as java.util.Date.
Craig
>
> -Patrick
>
> --
> Patrick Linskey
> BEA Systems, Inc.
>
> __
> _
> Notice: This email message, together with any attachments, may
> contain
> information of BEA Systems, Inc., its subsidiaries and
> affiliated
> entities, that may be confidential, proprietary, copyrighted
> and/or
> legally privileged, and is intended solely for the use of the
> individual
> or entity named in this message. If you are not the intended
> recipient,
> and have received this message in error, please immediately return
> this
> by email and then delete it.
>
>> -Original Message-
>> From: Michael Dick [mailto: [EMAIL PROTECTED]
>> Sent: Wednesday, February 07, 2007 12:57 PM
>> To: open-jpa-dev@incubator.apache.org
>> Subject: Exception when using java.sql.Date as an id
>>
>> Hi,
>>
>> I'm getting the following exception when I try to fetch an
>> entity with a
>> java.sql.Date as the id :
>>
>> java.lang.NoSuchMethodError: org.apache.openjpa.util.DateId.getId
>> ()Ljava/sql/Date;
>> at mikedd.entities.SqlDatePK.pcCopyKeyFieldsFromObjectId
>> (SqlDatePK.java
>> )
>> at mikedd.entities.SqlDatePK.pcNewInstance(SqlDatePK.java)
>> at
>> org.apache.openjpa.enhance.PCRegistry.newInstance(PCRegistry.java
>> :118)
>> at org.apache.openjpa.kernel.StateManagerImpl.initialize (
>> StateManagerImpl.java:247)
>> at
>> org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initializeState(
>> JDBCStoreManager.java:327)
>> at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initialize(
>> JDBCStoreManager.java:252)
>> at org.apache.openjpa.kernel.DelegatingStoreManager.initialize (
>> DelegatingStoreManager.java:108)
>> at org.apache.openjpa.kernel.ROPStoreManager.initialize(
>> ROPStoreManager.java:54)
>> at org.apache.openjpa.kernel.BrokerImpl.initialize
>> (BrokerImpl.java:868)
>> at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:826)
>> at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:743)
>> at org.apache.openjpa.kernel.DelegatingBroker.find (
>> DelegatingBroker.java:169)
>> at org.apache.openjpa.persistence.EntityManagerImpl.find(
>> EntityManagerImpl.java:346)
>> at
>> mikedd.tests.TestSqlDateId.testFindAfterClear (TestSqlDateId.java:25)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
>> at sun.reflect.NativeMethodAccessorImpl.invoke(
>> NativeMethodAccessorImpl.java:39)
>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(
>> DelegatingMethodAccessorImpl.java:25)
>> at java.lang.reflect.Method.invoke (Method.java:585)
>> at junit.framework.TestCase.runTest(TestCase.java :154)
>> . . .
>>
>> It's coming from the generated bytecode which expects there
>> to be a getId
>> method that returns the same type of the Id, however
>> java.sql.Date is using
>> the same ID class as java.util.Date. Do we need a separate class for
>> java.sql.Date?
>>
>> Here's the entity and testcase that I'm running (in case I
>> missed something
>> along the way)
>>
>> Entity :
>> import java.sql.Date;
>>
>> import javax.persistence.Entity;
>> import javax.persistence.Id ;
>>
>> @Entity
>> public class SqlDatePK {
>>
>> @Id
>> private Date id;
>> private String name;
>>
>> . . .
>> }
>>
>> Testcase :
>> public void testFindAfterClear() {
>> SqlDatePK sql;
>>
>> EntityManager em = _emf.createEntityManager();
>>
>> long ms = 101010; // arbitrary date.
>> java.sql.Date date = new java.sql.Date(ms);
>>
>> em.getTransaction().begin();
>>
>> sql = new SqlDatePK();
>> sql.setId(date);
>> em.persist(sql);
>>
>> em.getTransaction().commit();
>>
>> em.clear();
>> sql = null;
>> sql = em.find(SqlDatePK.class , date);
>>
>> . . .
>> }
>>
>> Thanks in advance,
>> --
>> -Michael Dick
>>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O,
Re: Exception when using java.sql.Date as an id
On Feb 7, 2007, at 1:55 PM, Patrick Linskey wrote:
It's coming from the generated bytecode which expects there
to be a getId
method that returns the same type of the Id, however
java.sql.Date is using
the same ID class as java.util.Date. Do we need a separate class for
java.sql.Date?
It looks like we either need a separate type for java.sql.Date (and
presumably java.sql.Timestamp), or we need to change the logic to
accept
a getId() method that returns a type that is assignable from the id
field's type.
It's probably cleaner if we have separate classes for the different
types. That is, have the getId method in the new
org.apache.openjpa.util.SQLDateId return the proper type
(java.sql.Date). After all, java.sql.{Date, Time, Timestamp} are not
really the same as java.util.Date.
Craig
-Patrick
--
Patrick Linskey
BEA Systems, Inc.
__
_
Notice: This email message, together with any attachments, may
contain
information of BEA Systems, Inc., its subsidiaries and
affiliated
entities, that may be confidential, proprietary, copyrighted
and/or
legally privileged, and is intended solely for the use of the
individual
or entity named in this message. If you are not the intended
recipient,
and have received this message in error, please immediately return
this
by email and then delete it.
-Original Message-
From: Michael Dick [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 07, 2007 12:57 PM
To: open-jpa-dev@incubator.apache.org
Subject: Exception when using java.sql.Date as an id
Hi,
I'm getting the following exception when I try to fetch an
entity with a
java.sql.Date as the id :
java.lang.NoSuchMethodError: org.apache.openjpa.util.DateId.getId
()Ljava/sql/Date;
at mikedd.entities.SqlDatePK.pcCopyKeyFieldsFromObjectId
(SqlDatePK.java
)
at mikedd.entities.SqlDatePK.pcNewInstance(SqlDatePK.java)
at
org.apache.openjpa.enhance.PCRegistry.newInstance(PCRegistry.java
:118)
at org.apache.openjpa.kernel.StateManagerImpl.initialize (
StateManagerImpl.java:247)
at
org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initializeState(
JDBCStoreManager.java:327)
at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initialize(
JDBCStoreManager.java:252)
at org.apache.openjpa.kernel.DelegatingStoreManager.initialize(
DelegatingStoreManager.java:108)
at org.apache.openjpa.kernel.ROPStoreManager.initialize(
ROPStoreManager.java:54)
at org.apache.openjpa.kernel.BrokerImpl.initialize
(BrokerImpl.java:868)
at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:826)
at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:743)
at org.apache.openjpa.kernel.DelegatingBroker.find (
DelegatingBroker.java:169)
at org.apache.openjpa.persistence.EntityManagerImpl.find(
EntityManagerImpl.java:346)
at
mikedd.tests.TestSqlDateId.testFindAfterClear(TestSqlDateId.java:25)
at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(
NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(
DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke (Method.java:585)
at junit.framework.TestCase.runTest(TestCase.java:154)
. . .
It's coming from the generated bytecode which expects there
to be a getId
method that returns the same type of the Id, however
java.sql.Date is using
the same ID class as java.util.Date. Do we need a separate class for
java.sql.Date?
Here's the entity and testcase that I'm running (in case I
missed something
along the way)
Entity :
import java.sql.Date;
import javax.persistence.Entity;
import javax.persistence.Id;
@Entity
public class SqlDatePK {
@Id
private Date id;
private String name;
. . .
}
Testcase :
public void testFindAfterClear() {
SqlDatePK sql;
EntityManager em = _emf.createEntityManager();
long ms = 101010; // arbitrary date.
java.sql.Date date = new java.sql.Date(ms);
em.getTransaction().begin();
sql = new SqlDatePK();
sql.setId(date);
em.persist(sql);
em.getTransaction().commit();
em.clear();
sql = null;
sql = em.find(SqlDatePK.class, date);
. . .
}
Thanks in advance,
--
-Michael Dick
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!
smime.p7s
Description: S/MIME cryptographic signature
RE: Exception when using java.sql.Date as an id
> It's coming from the generated bytecode which expects there
> to be a getId
> method that returns the same type of the Id, however
> java.sql.Date is using
> the same ID class as java.util.Date. Do we need a separate class for
> java.sql.Date?
It looks like we either need a separate type for java.sql.Date (and
presumably java.sql.Timestamp), or we need to change the logic to accept
a getId() method that returns a type that is assignable from the id
field's type.
-Patrick
--
Patrick Linskey
BEA Systems, Inc.
___
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.
> -Original Message-
> From: Michael Dick [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, February 07, 2007 12:57 PM
> To: open-jpa-dev@incubator.apache.org
> Subject: Exception when using java.sql.Date as an id
>
> Hi,
>
> I'm getting the following exception when I try to fetch an
> entity with a
> java.sql.Date as the id :
>
> java.lang.NoSuchMethodError: org.apache.openjpa.util.DateId.getId
> ()Ljava/sql/Date;
> at mikedd.entities.SqlDatePK.pcCopyKeyFieldsFromObjectId
> (SqlDatePK.java
> )
> at mikedd.entities.SqlDatePK.pcNewInstance(SqlDatePK.java)
> at
> org.apache.openjpa.enhance.PCRegistry.newInstance(PCRegistry.java
> :118)
> at org.apache.openjpa.kernel.StateManagerImpl.initialize (
> StateManagerImpl.java:247)
> at
> org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initializeState(
> JDBCStoreManager.java:327)
> at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initialize(
> JDBCStoreManager.java:252)
> at org.apache.openjpa.kernel.DelegatingStoreManager.initialize(
> DelegatingStoreManager.java:108)
> at org.apache.openjpa.kernel.ROPStoreManager.initialize(
> ROPStoreManager.java:54)
> at org.apache.openjpa.kernel.BrokerImpl.initialize
> (BrokerImpl.java:868)
> at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:826)
> at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:743)
> at org.apache.openjpa.kernel.DelegatingBroker.find (
> DelegatingBroker.java:169)
> at org.apache.openjpa.persistence.EntityManagerImpl.find(
> EntityManagerImpl.java:346)
> at
> mikedd.tests.TestSqlDateId.testFindAfterClear(TestSqlDateId.java:25)
> at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(
> NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(
> DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke (Method.java:585)
> at junit.framework.TestCase.runTest(TestCase.java:154)
> . . .
>
> It's coming from the generated bytecode which expects there
> to be a getId
> method that returns the same type of the Id, however
> java.sql.Date is using
> the same ID class as java.util.Date. Do we need a separate class for
> java.sql.Date?
>
> Here's the entity and testcase that I'm running (in case I
> missed something
> along the way)
>
> Entity :
> import java.sql.Date;
>
> import javax.persistence.Entity;
> import javax.persistence.Id;
>
> @Entity
> public class SqlDatePK {
>
> @Id
> private Date id;
> private String name;
>
> . . .
> }
>
> Testcase :
> public void testFindAfterClear() {
> SqlDatePK sql;
>
> EntityManager em = _emf.createEntityManager();
>
> long ms = 101010; // arbitrary date.
> java.sql.Date date = new java.sql.Date(ms);
>
> em.getTransaction().begin();
>
> sql = new SqlDatePK();
> sql.setId(date);
> em.persist(sql);
>
> em.getTransaction().commit();
>
> em.clear();
> sql = null;
> sql = em.find(SqlDatePK.class, date);
>
> . . .
> }
>
> Thanks in advance,
> --
> -Michael Dick
>
Re: Bug in insert of bidirectionally mapped many-to-one relationships
Jeff- Why is that order bad? Is it because it violates your foreign key constraints, or some other reason? If it is a foreign key issue, you need to tell OpenJPA to read foreign keys from the schema in order to ensure that SQL ordering is done correctly. You can do this by setting the "openjpa.jdbc.SchemaFactory" property to "native(ForeignKeys=true)". If that isn't the issue, can you clarify why this is causing problems? On Feb 7, 2007, at 9:09 AM, Jeff Melching wrote: I have a bidirectional mapping of a many-to-one relationship as listed below. If I have the following code: TestDatatypes blob = new TestDatatypes(); TestLookup lookup = new TestLookup(); Set tdts = new HashSet(); tdts.add(blob); lookup.setTestDatatypes(tdts); blob.setTestLookup(lookup); dao.insert(lookup); It works because the sql insert for the lookup table is ran first, but if I replace dao.insert(lookup) with dao. insert(blob), then the child sql is ran before the parent record has been inserted. as listed here: INSERT INTO TEST_DATATYPES (TEST_DATATYPES_ID, MODIFY_DATE, MODIFY_USER_ID, COMMENTS, INSERT_DATETIME, INSERT_USER_ID, IS_ACTIVE, IS_TEST, TEST_AMT, TEST_DATATYPES_NAME, TEST_DATE, TEST_DATETIME, TEST_IND, TEST_TIME, TEST_TIMEZONE, VER_ID, TEST_LOOKUP_ID) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?) [params=(long) 359, (Timestamp) 2007-02-06 10:07:12.468, (long) 1, (null) null, (Timestamp) 2007-02-06 10:07:11.671, (long) 34, (int) 1, (int) 0, (double) 0.0, (null) null, (null) null, (null) null, (null) null, (null) null, (null) null, (int) 1, (long) 40] INSERT INTO I3.TEST_LOOKUP (TEST_LOOKUP_ID, MODIFY_DATE, MODIFY_USER_ID, COMMENTS, IS_ACTIVE, TEST_LOOKUP_ABBR, TEST_LOOKUP_ALT_NAME, TEST_LOOKUP_CODE, TEST_LOOKUP_NAME, TEST_LOOKUP_SEQ, VER_ID) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?) [params=(long) 40, (Timestamp) 2007-02-06 10:07:12.531, (long) 1, (String) my lookup, (int) 1, (String) Abbrev, (String) alt name, (String) CODE, (null) null, (int) 0, (int) 1] I believe this to be a bug as I have tried the same mappings with other jpa implementations and it works fine. sequence-name="SEQ_TEST_DATATYPES_ID" allocation- size="1" /> ... sequence-name="SEQ_TEST_LOOKUP_ID" allocation- size="1" /> ...
Exception when using java.sql.Date as an id
Hi,
I'm getting the following exception when I try to fetch an entity with a
java.sql.Date as the id :
java.lang.NoSuchMethodError: org.apache.openjpa.util.DateId.getId
()Ljava/sql/Date;
at mikedd.entities.SqlDatePK.pcCopyKeyFieldsFromObjectId (SqlDatePK.java
)
at mikedd.entities.SqlDatePK.pcNewInstance(SqlDatePK.java)
at org.apache.openjpa.enhance.PCRegistry.newInstance(PCRegistry.java
:118)
at org.apache.openjpa.kernel.StateManagerImpl.initialize (
StateManagerImpl.java:247)
at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initializeState(
JDBCStoreManager.java:327)
at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initialize(
JDBCStoreManager.java:252)
at org.apache.openjpa.kernel.DelegatingStoreManager.initialize(
DelegatingStoreManager.java:108)
at org.apache.openjpa.kernel.ROPStoreManager.initialize(
ROPStoreManager.java:54)
at org.apache.openjpa.kernel.BrokerImpl.initialize (BrokerImpl.java:868)
at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:826)
at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:743)
at org.apache.openjpa.kernel.DelegatingBroker.find (
DelegatingBroker.java:169)
at org.apache.openjpa.persistence.EntityManagerImpl.find(
EntityManagerImpl.java:346)
at mikedd.tests.TestSqlDateId.testFindAfterClear(TestSqlDateId.java:25)
at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(
NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(
DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke (Method.java:585)
at junit.framework.TestCase.runTest(TestCase.java:154)
. . .
It's coming from the generated bytecode which expects there to be a getId
method that returns the same type of the Id, however java.sql.Date is using
the same ID class as java.util.Date. Do we need a separate class for
java.sql.Date?
Here's the entity and testcase that I'm running (in case I missed something
along the way)
Entity :
import java.sql.Date;
import javax.persistence.Entity;
import javax.persistence.Id;
@Entity
public class SqlDatePK {
@Id
private Date id;
private String name;
. . .
}
Testcase :
public void testFindAfterClear() {
SqlDatePK sql;
EntityManager em = _emf.createEntityManager();
long ms = 101010; // arbitrary date.
java.sql.Date date = new java.sql.Date(ms);
em.getTransaction().begin();
sql = new SqlDatePK();
sql.setId(date);
em.persist(sql);
em.getTransaction().commit();
em.clear();
sql = null;
sql = em.find(SqlDatePK.class, date);
. . .
}
Thanks in advance,
--
-Michael Dick
[jira] Created: (OPENJPA-131) Dynamic property support
Dynamic property support Key: OPENJPA-131 URL: https://issues.apache.org/jira/browse/OPENJPA-131 Project: OpenJPA Issue Type: New Feature Components: kernel Reporter: Patrick Linskey Currently, OpenJPA needs fields to exist in classes in order to load data into the VM. It would be great if instead, it were possible to issue a query and get back a java.util.Map of key-value pairs corresponding to the data requested, or if it were possible to have a field of type Map in an instance that was used to access all "dynamic" keys and their values. This would be useful for user-mutated schemas, or for open content, such as is available in XML. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OPENJPA-131) Dynamic property support
[ https://issues.apache.org/jira/browse/OPENJPA-131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Linskey updated OPENJPA-131: Priority: Minor > Dynamic property support > > > Key: OPENJPA-131 > URL: https://issues.apache.org/jira/browse/OPENJPA-131 > Project: OpenJPA > Issue Type: New Feature > Components: kernel >Reporter: Patrick Linskey >Priority: Minor > > Currently, OpenJPA needs fields to exist in classes in order to load data > into the VM. It would be great if instead, it were possible to issue a query > and get back a java.util.Map of key-value pairs corresponding to the data > requested, or if it were possible to have a field of type Map in an instance > that was used to access all "dynamic" keys and their values. This would be > useful for user-mutated schemas, or for open content, such as is available in > XML. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OPENJPA-130) Streaming LOB support
Streaming LOB support
-
Key: OPENJPA-130
URL: https://issues.apache.org/jira/browse/OPENJPA-130
Project: OpenJPA
Issue Type: New Feature
Components: jdbc, jpa, kernel, datacache
Reporter: Patrick Linskey
BLOB and CLOB fields can only be mapped in their entirety in OpenJPA. It would
be nice to support fields of type java.io.InputStream (for BLOBs) and
java.io.Reader (for CLOBs).
The usage pattern could look like so:
@Entity
public class Employee {
...
private InputStream photoStream;
public void setPhotoStream(InputStream in) {
photoStream = in;
}
public InputStream getPhotoStream() {
return photoStream;
}
}
So, when the user wants to provide a stream, she will set the InputStream
field, and when the user wants to obtain a stream, she will use the field.
The behavior of such an implementation would be a bit different than how other
fields work, in that if the user set the stream and then consumed it within a
single transaction, presumably no data would be written out to the database at
commit time. But that is the nature of streams.
(FTR, I think that I stole this idea from an email Craig Russell sent out years
ago.)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (OPENJPA-129) Oracle transaction log / DataCache integration
Oracle transaction log / DataCache integration -- Key: OPENJPA-129 URL: https://issues.apache.org/jira/browse/OPENJPA-129 Project: OpenJPA Issue Type: New Feature Components: datacache, jdbc Environment: Oracle Reporter: Patrick Linskey It'd be nice to support directly parsing Oracle transaction logs for cache expiration notification. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OPENJPA-127) Auto-cluster-detecting cache implementation
Auto-cluster-detecting cache implementation --- Key: OPENJPA-127 URL: https://issues.apache.org/jira/browse/OPENJPA-127 Project: OpenJPA Issue Type: New Feature Components: datacache Reporter: Patrick Linskey It would be great if OpenJPA could auto-detect other machines in a cache cluster. There are a lot of ways to get there, including integrating with some other cache that does that, using ActiveMQ's auto-configuring stuff, or doing our own multicast work. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OPENJPA-128) Automatic cache pre-fill on server start
Automatic cache pre-fill on server start Key: OPENJPA-128 URL: https://issues.apache.org/jira/browse/OPENJPA-128 Project: OpenJPA Issue Type: New Feature Reporter: Patrick Linskey It'd be nice to have some means to automatically pre-fill the cache when a node starts up, either by copying from a different node or from a serialized image on disk, or by issuing some pre-specified queries. I really like the idea of just letting the user specify something like so: Although in that last example, we'd really want some way to specify a bit more detail about which pages of the data to use, as you would in single-string JDOQL. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OPENJPA-126) EntityManagers cannot be serialized
EntityManagers cannot be serialized --- Key: OPENJPA-126 URL: https://issues.apache.org/jira/browse/OPENJPA-126 Project: OpenJPA Issue Type: New Feature Components: kernel, jpa Reporter: Patrick Linskey EntityManagers are not serializable or externalizable. This makes passivation of an EntityManager a difficult task. We should investigate how to externalize an EntityManager in a meaningful way. This could mean just writing out a stub that contains configuration information (potentially even just the persistence unit name, or the Configuration's ID), or it could mean actually serializing some or all of the local transactional cache to disk. The implications for the functionality available after deserialization would differ depending on the approach taken. I would like to see an implementation that efficiently wrote all the unflushed, dirty objects to disk. This would probably be best implemented via a writeReplace() strategy, to avoid handling all the transient fields in a Broker. Deserialization would then turn into a factory lookup plus some sort of in-place reattachment of the deserialized unflushed instances. Of course, if the entity instances themselves were not serializable, it would be difficult to write them to disk. Theoretically, we could just write out the corresponding StateManagers, and track the changed fields ourselves. I do not think that this is a good approach, however, since it would cause the deserialized objects to lose any non-persistent state after deserialization. I think that it is fair to require that instances be declared Serializable in order to use this feature. (We could optimize this a tad by detecting if an instance has only persistent fields, and if so, do our own serialization work.) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OPENJPA-125) OpenJPA-specific metadata cannot be specified in XML descriptors
[ https://issues.apache.org/jira/browse/OPENJPA-125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Linskey updated OPENJPA-125: Component/s: jpa Priority: Critical > OpenJPA-specific metadata cannot be specified in XML descriptors > > > Key: OPENJPA-125 > URL: https://issues.apache.org/jira/browse/OPENJPA-125 > Project: OpenJPA > Issue Type: New Feature > Components: jpa >Reporter: Patrick Linskey >Priority: Critical > > OpenJPA includes a number of annotations that extend the behavior of the JPA > specification. Currently, these annotations cannot be specified in an XML > descriptor. We must create an XSD that allows XML-based configuration of > these settings. > Additionally, to address OPENJPA-87, we should come up with a good story for > when only spec-level XML is used and OpenJPA annotations are also used. > Currently, as reported in OPENJPA-87, such a configuration causes us to > ignore the OpenJPA annotations. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OPENJPA-125) OpenJPA-specific metadata cannot be specified in XML descriptors
OpenJPA-specific metadata cannot be specified in XML descriptors Key: OPENJPA-125 URL: https://issues.apache.org/jira/browse/OPENJPA-125 Project: OpenJPA Issue Type: New Feature Reporter: Patrick Linskey OpenJPA includes a number of annotations that extend the behavior of the JPA specification. Currently, these annotations cannot be specified in an XML descriptor. We must create an XSD that allows XML-based configuration of these settings. Additionally, to address OPENJPA-87, we should come up with a good story for when only spec-level XML is used and OpenJPA annotations are also used. Currently, as reported in OPENJPA-87, such a configuration causes us to ignore the OpenJPA annotations. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Bug in insert of bidirectionally mapped many-to-one relationships
I have a bidirectional mapping of a many-to-one relationship as listed below. If I have the following code: TestDatatypes blob = new TestDatatypes(); TestLookup lookup = new TestLookup(); Set tdts = new HashSet(); tdts.add(blob); lookup.setTestDatatypes(tdts); blob.setTestLookup(lookup); dao.insert(lookup); It works because the sql insert for the lookup table is ran first, but if I replace dao.insert(lookup) with dao. insert(blob), then the child sql is ran before the parent record has been inserted. as listed here: INSERT INTO TEST_DATATYPES (TEST_DATATYPES_ID, MODIFY_DATE, MODIFY_USER_ID, COMMENTS, INSERT_DATETIME, INSERT_USER_ID, IS_ACTIVE, IS_TEST, TEST_AMT, TEST_DATATYPES_NAME, TEST_DATE, TEST_DATETIME, TEST_IND, TEST_TIME, TEST_TIMEZONE, VER_ID, TEST_LOOKUP_ID) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?) [params=(long) 359, (Timestamp) 2007-02-06 10:07:12.468, (long) 1, (null) null, (Timestamp) 2007-02-06 10:07:11.671, (long) 34, (int) 1, (int) 0, (double) 0.0, (null) null, (null) null, (null) null, (null) null, (null) null, (null) null, (int) 1, (long) 40] INSERT INTO I3.TEST_LOOKUP (TEST_LOOKUP_ID, MODIFY_DATE, MODIFY_USER_ID, COMMENTS, IS_ACTIVE, TEST_LOOKUP_ABBR, TEST_LOOKUP_ALT_NAME, TEST_LOOKUP_CODE, TEST_LOOKUP_NAME, TEST_LOOKUP_SEQ, VER_ID) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?) [params=(long) 40, (Timestamp) 2007-02-06 10:07:12.531, (long) 1, (String) my lookup, (int) 1, (String) Abbrev, (String) alt name, (String) CODE, (null) null, (int) 0, (int) 1] I believe this to be a bug as I have tried the same mappings with other jpa implementations and it works fine. ... ...
[jira] Updated: (OPENJPA-124) JOnAS integration: OpenJPA should auto-detect the JOnAS transaction manager
[ https://issues.apache.org/jira/browse/OPENJPA-124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Linskey updated OPENJPA-124: Priority: Minor > JOnAS integration: OpenJPA should auto-detect the JOnAS transaction manager > --- > > Key: OPENJPA-124 > URL: https://issues.apache.org/jira/browse/OPENJPA-124 > Project: OpenJPA > Issue Type: New Feature > Components: third-party > Environment: JOnAS application server >Reporter: Patrick Linskey >Priority: Minor > > OpenJPA does not automatically find the TransactionManager when deployed in a > JOnAS environment. We should modify AutomaticManagedRuntime, either to detect > JOnAS, or to always look at java:comp/UserTransaction. (JOnAS's > UserTransaction is also their TransactionManager.) > See > http://hanzz.zapto.org/index.php?option=com_content&task=view&id=105&Itemid=31 > for details. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OPENJPA-124) JOnAS integration: OpenJPA should auto-detect the JOnAS transaction manager
JOnAS integration: OpenJPA should auto-detect the JOnAS transaction manager --- Key: OPENJPA-124 URL: https://issues.apache.org/jira/browse/OPENJPA-124 Project: OpenJPA Issue Type: New Feature Components: third-party Environment: JOnAS application server Reporter: Patrick Linskey OpenJPA does not automatically find the TransactionManager when deployed in a JOnAS environment. We should modify AutomaticManagedRuntime, either to detect JOnAS, or to always look at java:comp/UserTransaction. (JOnAS's UserTransaction is also their TransactionManager.) See http://hanzz.zapto.org/index.php?option=com_content&task=view&id=105&Itemid=31 for details. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
