Dain,
When you mention the CMP test suite are you referring to the CTS TCK? If
so, how does CMP correspond to EJB's and their use of JPA (in the EJB3
sense)? I understand your request. I'm just trying to understand whether
this is a requirement or just a bad test case in the CTS TCK. The JPA
I believe that OpenJPA will allow float pk fields, it's just that
there's no built-in id class for them (see util.LongId, ShortId,
etc). So you'd have to either add a built-in id class and alter
OpenJPA's internal code to use it appropriately, or create your own
id class and use it via
Although the spec clearly recommends against the use of floating
points,
floats are a primitive type (or the Float wrapper) and need to be
allowed.
With no special AllowStupidApproximatePrimaryKeys flag. :-)
Am I trying to read too much into the spec or Dain's request? This
seems
Hi,
I'm hitting a bit of a snag with the staging repository for release 0.9.7.
Recently we made changes to remove -project from our the zip file names. The
problem is that the maven install and deploy goals ignore the names we
provide and generate their own names (
Need to support floating point primary keys
---
Key: OPENJPA-214
URL: https://issues.apache.org/jira/browse/OPENJPA-214
Project: OpenJPA
Issue Type: Bug
Components: jdbc
Affects
Hi Michael,
On Apr 10, 2007, at 3:40 PM, Michael Dick wrote:
Hi Craig,
Well I didn't intentionally remove them :-). It looks like they
were removed
by the maven plugin and this is one of the automated commits that
it does.
Looks like another gotcha with the tool.
The maven developers
[
https://issues.apache.org/jira/browse/OPENJPA-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12488108
]
Michael Dick commented on OPENJPA-211:
--
It looks like WASManagedRuntime is having trouble finding the
If a provider does not qualify as the provider for the named
persistence unit,
it must return null when createEntityManagerFactory is invoked on it.
That's what the provider must do when
PersistenceProvider.createEntityManagerFactory() is called, not what the
Persistence class must do.
As
Does anyone vehemently object to putting -project back into
the names for
the 0.9.7 release?
I don't vehemently object for the 0.9.7 release, but I do vehemently
object for the 1.0 release. I don't like these random bugs / limitations
of our build process making their way into the project
Michael-
I personally think that keeping -project- in the artifact zip name
is tolerable. I too had looked around (albeit briefly) for a solution
to this a while ago, and found none.
Once OpenJPA is out of incubation and we are deploying releases to
the Apache mirror system, we'll
From findAllProviders():
EnumerationURL resources =
loader.getResources(META-INF/services/ +
PersistenceProvider.class.getName());
If no resources are found, we've got a useful nugget of information: no
persistence providers are available in the current classloader.
Later
Are we looking at different classes? I can't find the code in
javax.persistence.Persistence under GlassFish that looks up persistence units.
It's all delegated to the providers.
thanks,
-marina
Patrick Linskey wrote:
If a provider does not qualify as the provider for the named
persistence
On 4/11/07, Patrick Linskey [EMAIL PROTECTED] wrote:
Does anyone vehemently object to putting -project back into
the names for
the 0.9.7 release?
I don't vehemently object for the 0.9.7 release, but I do vehemently
object for the 1.0 release. I don't like these random bugs / limitations
of
You're right, if / when we bypass the deploy phase and execute scp (or
something similar) ourselves then it'll be easy to put in the renaming
logic.
Thanks Patrick and Marc,
On 4/11/07, Marc Prud'hommeaux [EMAIL PROTECTED] wrote:
Michael-
I personally think that keeping -project- in the
Hi,
I am trying to run standalone application access the database using spring
,openjpa.
part of code in main method
EntityManagerFactory factory = Persistence.createEntityManagerFactory(tsf);
EntityManager em = factory.createEntityManager();
On 4/11/07, saidulu chitipolu [EMAIL PROTECTED] wrote:
your earliest suggetions are valuable
You may want to take a look at the following thread -
http://www.mail-archive.com/open-jpa-dev@incubator.apache.org/msg02770.html.
Make sure that your class is @Entity-annotated, PCEnhance it and
Question...
Now that Abe has graciously resolved OpenJPA-134 (
https://issues.apache.org/jira/browse/OPENJPA-134), I would really like to
see this get included into the 0.9.7 release. This fix looks to resolve the
redundant sql joins that were dogging the performance of certain
benchmarks. By
[
https://issues.apache.org/jira/browse/OPENJPA-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12488191
]
david zhang commented on OPENJPA-211:
-
It seems WAS has no problem finding the implementation class: [EMAIL
Generally in favor of including this performance patch with the
release. Just a few questions:
1. How good is the patch? Has it been put through whatever extensive
Unit Tests tests anyone has?
2. How easy is it to respin the release? I'd hope that this is a
matter of a few hours but I'm
Persistent Java classes when used in Query use an alias (which is, be
deafult, the unqualified name of the Java class). However, the alias is
known to the runtime once the Java class is loaded in to JVM. When the
very first JPA operation is a query and the persistence unit does not
explictly
Hi Pinaki,
On Apr 10, 2007, at 6:44 PM, Pinaki Poddar wrote:
provide a patch.
Will such a patch be given to Glassfish project?
But some kind of committer-level privilege will be required, i
suppose.
have added few more informative messages to distinguish between
different ways persistence
1. How good is the patch? Has it been put through whatever extensive
Unit Tests tests anyone has?
It passes all the OpenJPA tests against Derby and HSQL. It also passes
some other integration tests as well.
2. How easy is it to respin the release? I'd hope that this is a
matter of a few
1. How good is the patch? Has it been put through whatever extensive
Unit Tests tests anyone has?
It passes all the OpenJPA tests against Derby and HSQL. It also passes
some other integration tests as well.
It also works with DB2. I haven't been able to check out the performance
benchmark
Hello Craig,
Done.
Thanks for your advice.
Please review:
https://glassfish.dev.java.net/issues/show_bug.cgi?id=2814
Pinaki Poddar
BEA Systems
415.402.7317
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 11, 2007 5:11 PM
To:
On Apr 11, 2007, at 7:28 AM, Kevin Sutter wrote:
Okay, I looked at the spec a bit closer and it looks like we need
to allow
for floats as primary keys:
The primary key (or field or property of a composite primary key)
should be
one of the following types:
any Java primitive type; any
Isn't it called an entity name in the JPA spec?
thanks,
-marina
Pinaki Poddar wrote:
Persistent Java classes when used in Query use an alias (which is, be
deafult, the unqualified name of the Java class). However, the alias is
known to the runtime once the Java class is loaded in to JVM. When
Abe,
I have verified this fix with EagerFetchMode parallel and join. However,
there is an outstanding problem for the following query with inner join
fetch while left join fetch generates correct SQL; the inner join fetch
generates extra unneeded left join:
select o from Order o inner join
unneeded left join SQL for queries with inner join fetch, related to issue
OPENJPA-134
Key: OPENJPA-215
URL: https://issues.apache.org/jira/browse/OPENJPA-215
[
https://issues.apache.org/jira/browse/OPENJPA-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12488232
]
david zhang commented on OPENJPA-211:
-
No use, test on both WAS test environment and WAS standalone server,
29 matches
Mail list logo
