[jira] Created: (OPENJPA-56) in derby concat with input parameter needs a cast, otherwise becomes long varchar and some operations do not work
in derby concat with input parameter needs a cast, otherwise becomes long
varchar and some operations do not work
-
Key: OPENJPA-56
URL: http://issues.apache.org/jira/browse/OPENJPA-56
Project: OpenJPA
Issue Type: Bug
Components: query
Environment: Windows xp, derby, openjpa version 443432.
Reporter: George Hongell
Attachments: failureEntities.jar
run on version 443432.
in derby concat with input parameter needs a cast, otherwise becomes long
varchar and some operations do not work
(NOTE:already done if concat is inside substring eg.
substring(concat(xxx,yyy),n,m)
EJBQL:
select d from EmpBean e left join e.dept d where concat(d.name, 'ahmad') =
'AhmadDept'
OPENJPA ERROR OR SQL PUSHDOWN:
Comparisons between 'LONG VARCHAR' and 'LONG VARCHAR' are not supported.
{SELECT t1.deptno, t1.budget, t1.mgr_empid, t1.name, t1.reportsTo_deptno FROM
EmpBean t0 LEFT OUTER JOIN DeptBean t1 ON t0.dept_deptno = t1.deptno WHERE
((t1.name||?) = ?)} [code=3, state=42818]
SUGGESTED SQL PUSHDOWN:
select t1.deptno, t1.name FROM EmpBean t0 LEFT OUTER JOIN DeptBean t1 ON
t0.dept_deptno = t1.deptno WHERE (cast((t1.name||?) as Varchar(1000))) = ?
{String ahmad, String AhmadDept}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (OPENJPA-56) in derby concat with input parameter needs a cast, otherwise becomes long varchar and some operations do not work
[ http://issues.apache.org/jira/browse/OPENJPA-56?page=all ]
George Hongell updated OPENJPA-56:
--
Attachment: failureEntities.jar
entity java files and derby ddl script to use to recreate this issue
> in derby concat with input parameter needs a cast, otherwise becomes long
> varchar and some operations do not work
> -
>
> Key: OPENJPA-56
> URL: http://issues.apache.org/jira/browse/OPENJPA-56
> Project: OpenJPA
> Issue Type: Bug
> Components: query
> Environment: Windows xp, derby, openjpa version 443432.
>Reporter: George Hongell
> Attachments: failureEntities.jar
>
>
> run on version 443432.
> in derby concat with input parameter needs a cast, otherwise becomes long
> varchar and some operations do not work
> (NOTE:already done if concat is inside substring eg.
> substring(concat(xxx,yyy),n,m)
> EJBQL:
> select d from EmpBean e left join e.dept d where concat(d.name, 'ahmad') =
> 'AhmadDept'
>
> OPENJPA ERROR OR SQL PUSHDOWN:
> Comparisons between 'LONG VARCHAR' and 'LONG VARCHAR' are not supported.
> {SELECT t1.deptno, t1.budget, t1.mgr_empid, t1.name, t1.reportsTo_deptno FROM
> EmpBean t0 LEFT OUTER JOIN DeptBean t1 ON t0.dept_deptno = t1.deptno WHERE
> ((t1.name||?) = ?)} [code=3, state=42818]
> SUGGESTED SQL PUSHDOWN:
> select t1.deptno, t1.name FROM EmpBean t0 LEFT OUTER JOIN DeptBean t1 ON
> t0.dept_deptno = t1.deptno WHERE (cast((t1.name||?) as Varchar(1000))) = ?
> {String ahmad, String AhmadDept}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (OPENJPA-24) Allow OpenJPA to be extensible
[ http://issues.apache.org/jira/browse/OPENJPA-24?page=comments#action_12436323 ] Michael Dick commented on OPENJPA-24: - Thanks Abe, I was able to load a custom EMF with your changes. I might have more questions when I get a chance to experiment a little more. > Allow OpenJPA to be extensible > -- > > Key: OPENJPA-24 > URL: http://issues.apache.org/jira/browse/OPENJPA-24 > Project: OpenJPA > Issue Type: Bug > Components: kernel >Reporter: Kevin Sutter > Assigned To: Kevin Sutter > > The current OpenJPA architecture is not extendable to other implementations. > For example, if somebody wanted to provide their own PersistenceProvider > implementation, simply extending the > org.apache.openjpa.PersistenceProviderImpl would not suffice due to the > dependencies in the ConfigurationProviderImpl. The discussion for this > improvement was started on the dev mailing list. Once it was determined that > there was more to this request than a simple conditional or two, we decided > to open a JIRA report. > The complete history of this request can be found in the OpenJPA dev mailing > list. The first message was posted by me (Kevin Sutter) on August 14, titled > "Extending the OpenJPA Implementation". I will attempt to paraphrase the > current state of the problem... > We have three main players in this issue. The PersistenceProvider, the > ConfigurationProvider, and the ProductDerivation (along with the various > implementations of these interfaces). Currently, the ConfigurationProvider > is in the lib and is unaware of any specific persistence requirements. The > ProductDerivation is in the kernel and, unfortunately, is aware of > persistence requirements, specifically the spec and store types. Abe's > postings have indicated that we need to make these two interfaces more aware > of each other and work with each other. We need to start with either making > ConfigurationProvider more persistence-aware and move it into kernel, or make > ProductDerivations less persistence-aware and move it into lib. The latter > approach is preferred. > After we get this re-organization of the base framework complete, we still > have a couple of other issues ot resolve: > * Still need the ability to extend EMF's through a ProductDerivation. > This should be doable by adding a new PluginValue to indicate what class of > EMF to load. > * There is still a question as to whether we will need to provide a > custom PersistenceProviderImpl and ConfigurationProviderImpl pair. I still > think this will be necessary. And, one of Abe's posts indicated that this > might help with class loading issues when multiple versions of OpenJPA-based > implementations are available in the same system. > I also posted these questions last Friday. (Abe has responded with some > answers, but I wanted to get this JIRA report created before trying to > paraphrase his answers.) > * You mention in several places about separating away the notion of > specs and stores. In a general sense, I understand what these are. But, can > you elaborate on how these types are used in the ConfigurationProvider and > ProductDerivation interfaces? > * I've moved the ProductDerivation interface to the lib and added the > "load" methods from the ConfigurationProvider (as described in your previous > notes). And, I've started to clean up the implementations that depend on > these interfaces. But, concerning the implementation of the load methods... > Now that we need to return a ConfigurationProvider, would you expect that we > just new up a ConfigurationProviderImpl and then just call across to the > "load" methods on the implementation? Since we want to keep the > ProductDerivations stateless, I'm not sure how else you were expecting to > create a ConfigurationProvider to return on these "load" methods. > * Now that ConfigurationProvider is bare, the > ConfigurationTestConfigurationProvider doesn't have much function. I'll need > to take a look to see if this is even required any longer. > * Can you shed a bit more light on the Configurations class? It doesn't > implement nor extend any interfaces or classes, but it seems to provide many > of the same methods as ConfigurationProvider, but as statics. And, it's > dependent on having a Provider. Can you explain the relationship of this > class in the bigger picture and how you think it might be affected by thes > changes? > That's enough for the initial JIRA report. We will now track this problem > here instead of the dev mailing list. Thanks. > Kevin -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, s
enhancement of persistent classes
Hello all... was on vacation for a bit... then the day job got in the way. Quick question for the folks more in the know than me. Reading this (http://people.apache.org/~mprudhom/openjpa/site/openjpa-project/manual/ref_guide_pc_enhance.html#ref_guide_pc_enhance_runtime_container), it seems like classes must be enhanced (either at build time or runtime) unless being deployed to a compliant EJB3 container, in which case that's part of the container's job. I just wanted to verify that I understand this correctly, and there's not some way to avoid having to enhance these things that I don't know about. I ask because you don't have to perform any kind of enhancement step in your build process when using Hibernate. I wouldn't be surprised if I'm missing something here, so if I said something stupid, please be gentle. Thanks... Bryan
Re: enhancement of persistent classes
Bryan- You are correct: OpenJPA does require enhancement of classes. This allows us to be much faster and more efficient for many operations than a purely reflection-based system can be. On Sep 20, 2006, at 2:12 PM, Bryan Noll wrote: Hello all... was on vacation for a bit... then the day job got in the way. Quick question for the folks more in the know than me. Reading this (http://people.apache.org/~mprudhom/openjpa/site/openjpa- project/manual/ ref_guide_pc_enhance.html#ref_guide_pc_enhance_runtime_container), it seems like classes must be enhanced (either at build time or runtime) unless being deployed to a compliant EJB3 container, in which case that's part of the container's job. I just wanted to verify that I understand this correctly, and there's not some way to avoid having to enhance these things that I don't know about. I ask because you don't have to perform any kind of enhancement step in your build process when using Hibernate. I wouldn't be surprised if I'm missing something here, so if I said something stupid, please be gentle. Thanks... Bryan
Re: enhancement of persistent classes
Fair enough... just wanted to be clear... Marc Prud'hommeaux wrote: Bryan- You are correct: OpenJPA does require enhancement of classes. This allows us to be much faster and more efficient for many operations than a purely reflection-based system can be. On Sep 20, 2006, at 2:12 PM, Bryan Noll wrote: Hello all... was on vacation for a bit... then the day job got in the way. Quick question for the folks more in the know than me. Reading this (http://people.apache.org/~mprudhom/openjpa/site/openjpa-project/manual/ref_guide_pc_enhance.html#ref_guide_pc_enhance_runtime_container), it seems like classes must be enhanced (either at build time or runtime) unless being deployed to a compliant EJB3 container, in which case that's part of the container's job. I just wanted to verify that I understand this correctly, and there's not some way to avoid having to enhance these things that I don't know about. I ask because you don't have to perform any kind of enhancement step in your build process when using Hibernate. I wouldn't be surprised if I'm missing something here, so if I said something stupid, please be gentle. Thanks... Bryan
Issue with GenerationType.IDENTITY?
Hi,
It seems that if I map an ID to an Identity Column, then, OpenJPA
automatically returns a type BigDecimal? I am not using this type
anywhere. It does not happen with other Integer or Long mappings, just with
generated strategy.
@Id
@GeneratedValue(strategy=GenerationType.IDENTITY)
@Column(name="ORDER_ID")
public Long getOrderId() {
return orderId;
}
public void setOrderId(Long orderId) {
this.orderId = orderId;
[9/19/06 17:44:23:750 EDT] 002d SystemOut O
<0|true|0.9.0-incubating-SNAPSHOT>
org.apache.openjpa.persistence.PersistenceException:
java.math.BigDecimalincompatible with
java.lang.Long
[9/19/06 17:44:23:750 EDT] 002d SystemOut O at
org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:1576)
[9/19/06 17:44:23:750 EDT] 002d SystemOut O at
org.apache.openjpa.kernel.StateManagerImpl.assignObjectId(
StateManagerImpl.java:475)
[9/19/06 17:44:23:750 EDT] 002d SystemOut O at
org.apache.openjpa.kernel.StateManagerImpl.assignField(StateManagerImpl.java
:554)
[9/19/06 17:44:23:750 EDT] 002d SystemOut O at
org.apache.openjpa.kernel.StateManagerImpl.beforeAccessField(
StateManagerImpl.java:1325)
[9/19/06 17:44:23:750 EDT] 002d SystemOut O at
org.apache.openjpa.kernel.StateManagerImpl.accessingField(
StateManagerImpl.java:1308)
Before I dig further, I thought I would check with the group first. Thanks.
Kevin
Re: enhancement of persistent classes
So... trying to wrap my head around this topic a bit more. Can one of you fellas clarify for me whether or not an eclipse plugin exists out there that enhances classes for you? Looking around the web a bit produced the following, which sort of leaves it hanging. http://forums.bea.com/bea/message.jspa?messageID=500039147&tstart=0 http://forums.bea.com/bea/message.jspa?messageID=600037521&tstart=0 Thanks in advance... Bryan Bryan Noll wrote: Fair enough... just wanted to be clear... Marc Prud'hommeaux wrote: Bryan- You are correct: OpenJPA does require enhancement of classes. This allows us to be much faster and more efficient for many operations than a purely reflection-based system can be. On Sep 20, 2006, at 2:12 PM, Bryan Noll wrote: Hello all... was on vacation for a bit... then the day job got in the way. Quick question for the folks more in the know than me. Reading this (http://people.apache.org/~mprudhom/openjpa/site/openjpa-project/manual/ref_guide_pc_enhance.html#ref_guide_pc_enhance_runtime_container), it seems like classes must be enhanced (either at build time or runtime) unless being deployed to a compliant EJB3 container, in which case that's part of the container's job. I just wanted to verify that I understand this correctly, and there's not some way to avoid having to enhance these things that I don't know about. I ask because you don't have to perform any kind of enhancement step in your build process when using Hibernate. I wouldn't be surprised if I'm missing something here, so if I said something stupid, please be gentle. Thanks... Bryan
