DerbyDictionary doesn't describe a working mapping for char fields.
---
Key: OPENJPA-221
URL: https://issues.apache.org/jira/browse/OPENJPA-221
Project: OpenJPA
Issue Type: Bug
[
https://issues.apache.org/jira/browse/OPENJPA-221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12489761
]
Patrick Linskey commented on OPENJPA-221:
-
What happens if, without your patch, you set the DBDictionary
The release is looking good with two items that should be addressed
and some nits. :)
Major issues:
- Mike's GPG key is present in site/docs/KEYS but this file needs to
be copied to http://incubator.apache.org/openjpa/KEYS as well. This
will make it easier to verify releases and matches the
Hi Eddie,
On Apr 18, 2007, at 8:46 AM, Eddie O'Neil wrote:
The release is looking good with two items that should be addressed
and some nits. :)
Major issues:
- Mike's GPG key is present in site/docs/KEYS but this file needs to
be copied to http://incubator.apache.org/openjpa/KEYS as well.
1. OK I think I will open a new issue for the bug
2. I will redo the formatting
3.To be able to use DBDictionary method we will have to change the signature
of the
toSelect(SQLBuffer selects, JDBCFetchConfiguration fetch,SQLBuffer from,
SQLBuffer where, SQLBuffer group,SQLBuffer having,
FOR READ ONLY clause getting generated for subselects
-
Key: OPENJPA-222
URL: https://issues.apache.org/jira/browse/OPENJPA-222
Project: OpenJPA
Issue Type: Bug
Components: jpa
[eko] Yeah, you're right that neithre of these are big deals
-- just empty directories. I did wonder if the TCK directory
had anything that TCK-related that shouldn't be public (like
how to run it), but I'll defer to you and Geir here.
The TCK dir only contains the bootstrap / glue to
- The binary distribution contains a new JAR file whose
license is unclear; this is:
binary-dist/lib/docbook-xsl-1.67.2.zip
That dependency is unnecessary -- it's needed to build the docs, but not
by the runtime.
-Patrick
--
Patrick Linskey
BEA Systems, Inc.
The TCK dir only contains the bootstrap / glue to invoke the TCK
from within our build system, and not the TCK itself.
[eko] Yeah -- I noticed. Just didn't know how paranoid folks tend to
be about this sort of stuff since TCK details seem to be kept under
wraps.
- The binary distribution
[
https://issues.apache.org/jira/browse/OPENJPA-221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12489820
]
Patrick Linskey commented on OPENJPA-221:
-
It's not surprising that the OpenJPA tests storeCharsAsNumbers
[eko] Yeah -- I noticed. Just didn't know how paranoid folks
tend to be about this sort of stuff since TCK details seem to
be kept under wraps.
None of this IP comes from the TCK itself. I don't think that the TCK
license bans people from putting IP that they create while running the
TCK
So Essentially we need to pass this subselect flag to
getForUpdateClause
method.I am not sure how would we do that without overriding
the method in
DB2Dictionary or chnaging the signatures in DBDictionary
which would affect
many other files
Understood. I think that this is a bit of a
This is there because we draw in all the dependencies that we
don't explicitly exclude in the openjpa-project/assembly.xml,
and at some point, someone (probably me) added docbook-xsl as
a dependency so as to ensure that the docbook processing
phase had access to the stylesheets.
Is it
I'm not understanding something, maybe someone could explain, and
obviously the comments I suggested in DBDictionary are completely
wrong, although I sure don't see why.
IIUC derby is a pure java db optimized for use with java and storing
java primitive types basically using java
Good idea ... I've gone ahead and done that. It should make things a
little easier to manage.
On Apr 18, 2007, at 10:45 AM, Patrick Linskey wrote:
This is there because we draw in all the dependencies that we
don't explicitly exclude in the openjpa-project/assembly.xml,
and at some
Hi,
IIUC derby is a pure java db optimized for use with java and
storing java primitive types basically using java
serialization. Why would openjpa want to store a char in
derby as an integer?
Because we've always done it that way. Is there a reason why we should
not be storing chars
Thanks Marc,
How do I upload my key to http://incubator.apache.org/openjpa/KEYS ? The
only documentation I've found indicates that I need to upload it, but not
where the key needs to go.
Before I create another release candidate (to remove the docbook jar),
should we try to address the other
Mike--
RE the KEYS file, you can just ssh to people.apache.org and check
the KEYS file out directly into /www/incubator.apache.org/openjpa/
directory. No uploading necessary! :)
To be sure -- the rest of the items are just nits which could mostly
be cleaned up just by deleting the
- commons-logging-1.0.4.jar (used only in
CommonsLogFactory when logging is configured to use commons)
I think that we should leave this out altogether. Anyone who wants to
use commons logging will presumably have commons logging.
- commons-pool-1.3.jar (used only in
Michael-
On Apr 18, 2007, at 11:35 AM, Michael Dick wrote:
Thanks Marc,
How do I upload my key to http://incubator.apache.org/openjpa/
KEYS ? The
only documentation I've found indicates that I need to upload it,
but not
where the key needs to go.
As Eddie mentioned, you should be able
- The source distribution contains a derby.log file at:
source-dist/openjpa-persistence-jdbc/derby.log
This is pretty easy to clean up, and I'll do that before I create
another release candidate.
I think I noticed a commit from Patrick that fixes this for
the future (I believe
When SychronizeMappings is set to buildSchema, as it always is for me (in
head-down development mode), every run of unit tests or app server is prefaced
by a large collection of spurious warnings. A specimen:
3635 myproj WARN [http-8080-Processor24] openjpa.jdbc.Schema - Existing
column id
On Apr 18, 2007, at 10:19 AM, Patrick Linskey wrote:
[eko] Yeah -- I noticed. Just didn't know how paranoid folks
tend to be about this sort of stuff since TCK details seem to
be kept under wraps.
None of this IP comes from the TCK itself. I don't think that the TCK
license bans people from
For the record, I'm still
+1 for release.
But if you want to cut another to fix the minor items that have been
surfaced, it's ok with me.
Craig
On Apr 18, 2007, at 11:42 AM, Eddie O'Neil wrote:
Mike--
RE the KEYS file, you can just ssh to people.apache.org and check
the KEYS file out
Is there any way to cause the OpenJPA schema builder to emit an index across
multiple columns? My attempt,
@Column(columnDefinition = bytea)
@Index(name = i_owner_md5, columnNames = { owner_id, md5 })
public byte[] getMd5()
{
return md5;
}
is silently misinterpreted, in that only the
I'd rather not cut another release, but I think we do need to resolve the
issue with the docbook jar. If we can live with the extra jar then the vote
can proceed.
If I go back and remove the jar, republish etc. I'm assuming we'll have to
restart the clock on the vote, correct me if I'm wrong in
... but we can run the incubator and the openjpa votes in parallel,
right? If we're pretty sure that with the removal of that jar, we'll be
happy, then we could rebuild and start off those two votes at the same
time.
-Patrick
--
Patrick Linskey
BEA Systems, Inc.
What error do you get?
I expect that it's joining extra data because your one-to-ones and
many-to-ones are marked up to use eager fetching. Note that eager
fetching is the default for one-to-one and many-to-one relations, so if
you have not marked up these relations as lazy, then they're
On Apr 18, 2007, at 12:53 PM, Patrick Linskey wrote:
... but we can run the incubator and the openjpa votes in parallel,
right? If we're pretty sure that with the removal of that jar,
we'll be
happy, then we could rebuild and start off those two votes at the same
time.
Yes, this is true.
Michael-
On Apr 18, 2007, at 12:27 PM, Michael Dick wrote:
I'd rather not cut another release, but I think we do need to
resolve the
issue with the docbook jar. If we can live with the extra jar then
the vote
can proceed.
Personally, I think it is sufficiently ugly to release with the
Jonathan-
It looks like we indeed do ignore the columnNames field of the index.
This is a bug, and I've entered it at:
https://issues.apache.org/jira/browse/OPENJPA-223
I don't think there is a workaround, unless the index is unique, in
which case you can use the JPA standard
[
https://issues.apache.org/jira/browse/OPENJPA-222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dick reassigned OPENJPA-222:
Assignee: David Wisneski
FOR READ ONLY clause getting generated for subselects
In general I agree with Patrick. I'm +0 regarding including Derby, it's nice
for the examples, but it just doesn't seem right to include a preferred
database . No logical reason, just personal preference.
On 4/18/07, Patrick Linskey [EMAIL PROTECTED] wrote:
- commons-logging-1.0.4.jar
On 4/18/07, Phill Moran [EMAIL PROTECTED] wrote:
The exception I get is null pointer from this line:
ListPerson results = (ListPerson) q.getResultList();
Could you show the query creation and the stack trace you're getting?
Jacek
--
Jacek Laskowski
http://www.JacekLaskowski.pl
On Apr 18, 2007, at 11:12 AM, Patrick Linskey wrote:
Hi,
IIUC derby is a pure java db optimized for use with java and
storing java primitive types basically using java
serialization. Why would openjpa want to store a char in
derby as an integer?
Because we've always done it that way. Is
Here it is:
[2007-04-18 18:37:07,937] INFO ca.BidSpec.testing.emall.UserFactoryTest Began
transaction (1): transaction manager
[EMAIL PROTECTED]; default rollback =
true
25547 WARN [main] openjpa.MetaData - Found duplicate query
PersonFXLastFirst in class ca.BidSpec.emall.user.Person.
Does that mean you store Strings as arrays of integers by
default for the same reason?
No.
Why is this different?
Because we've regularly run into problems with chars, and have found
that mapping them as ints by default gets around the problems.
There aren't any non-incubator openjpa
I probably should have worded that differently since I haven't run the tests
against DB2. I believe Dave's team has.
Dave, can you comment on how big the impact of OpenJPA-222 is?
On 4/18/07, Patrick Linskey [EMAIL PROTECTED] wrote:
I'm a little nervous about OpenJPA-222. From talking with
This isn't the last release of openjpa. What is the urgency for
fixing this before our major event (the last release before exiting
the incubator)?
Is this release planned to be bundled with some other significant
release?
Craig
On Apr 18, 2007, at 4:40 PM, Michael Dick wrote:
I
Hi there,
I have a list which is marked @ElementDependent and also CascadeType.ALL.
Adding and removing items from the list works fine, and those elements are
deleted from the database. When I try to delete the owning entity though, I
get the exception below.
I can delete the entity okay if I
40 matches
Mail list logo
