[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