[
https://issues.apache.org/jira/browse/OPENJPA-722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abe White resolved OPENJPA-722.
---
Resolution: Fixed
Applied V3 patch in SVN revision 700158.
> persist - clear - merge scena
[
https://issues.apache.org/jira/browse/OPENJPA-699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abe White resolved OPENJPA-699.
---
Resolution: Fixed
Applied v2 patch per comments in SVN revision 689518.
> SQLWarnings not hand
[
https://issues.apache.org/jira/browse/OPENJPA-699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625452#action_12625452
]
Abe White commented on OPENJPA-699:
---
If Joe is right then neither my proposed solu
[
https://issues.apache.org/jira/browse/OPENJPA-699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625423#action_12625423
]
Abe White commented on OPENJPA-699:
---
Why don't we just always skip SQL warn
[
https://issues.apache.org/jira/browse/OPENJPA-678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abe White resolved OPENJPA-678.
---
Resolution: Fixed
Fix Version/s: 1.3.0
Similar patch applied in SVN revision 686325
_impl and _fieldImpl are space for implementations to store
impl-specific data about the object or its fields. I don't recall
whether Kodo/OpenJPA currently uses this feature. Custom mappings
might.
On Thu, 2008-08-14 at 13:36 -0700, catalina wei wrote:
> Hi all,
> In order to develop a DataCach
[
https://issues.apache.org/jira/browse/OPENJPA-592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12597985#action_12597985
]
Abe White commented on OPENJPA-592:
---
Jason, will you be submitting a new patch
[
https://issues.apache.org/jira/browse/OPENJPA-592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12595629#action_12595629
]
Abe White commented on OPENJPA-592:
---
1: The patch proposes to use the table
[
https://issues.apache.org/jira/browse/OPENJPA-536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12591381#action_12591381
]
Abe White commented on OPENJPA-536:
---
Latest patch looks pretty good. Two minor det
[
https://issues.apache.org/jira/browse/OPENJPA-568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12588067#action_12588067
]
Abe White commented on OPENJPA-568:
---
As of revision 646082, I believe this patc
[
https://issues.apache.org/jira/browse/OPENJPA-564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abe White resolved OPENJPA-564.
---
Resolution: Fixed
Patch submitted in revision 647250.
> Set correct DBDictionary properties
[
https://issues.apache.org/jira/browse/OPENJPA-554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abe White resolved OPENJPA-554.
---
Resolution: Fixed
Applied suggested fix in revision 645589.
> The GetMapValue class should h
I believe parts of OpenJPA may rely on being able to stringify an id and
then reconstruct it using the id class's Class,string constructor. (And
if not OpenJPA, then certainly Kodo's JDO bindings).
On Fri, 2008-04-04 at 17:32 -0700, [EMAIL PROTECTED] wrote:
> I dont think anyone responded to t
Here's another option that might suit everyone:
- We change the enhancement so that a non-default auto-assigned pk field
makes an instance detached even in the absence of detached state, as I
proposed.
- If the entity doesn't use auto-assigned pk fields (and has no version
field) and detached stat
OpenJPA typically uses an enhancer-added "detached state field" to
differentiate newly-constructed instances that need to be inserted vs.
detached instances that need to be updated on merge. This is covered in
more detail in the user manual.
OpenJPA also allows users with version fields to manual
Joe --
I've been asked to help with this issue. Unfortunately SQL generation
is the messiest part of the OpenJPA codebase, and it'll take me some
time to remember how it all works. To start with, can you show me the
JPQL (or JDOQL) query that's generating the alias-less subselect?
Also, please
> If anyone could use a MSDN license for developing OpenJPA, please
> send me email so I can coordinate the number of licenses.
I'd like one.
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entitie
> Understood. I was however under the impression that correctly
> annotated relations would make it unnecessary to resort to database
> metadata to build a correct dependency graph --it appears that's
> not the case.
There are settings under which OpenJPA will assume all relations are
repr
> Is that a hint to set openjpa.jdbc.SchemaFactory=native
> (ForeignKeys=true)?
No. I'm saying that if these secret tests rely on OpenJPA to detect
foreign keys based on the above setting, then it's likely that the
problem is in OpenJPA's ability to detect the existing foreign keys
rather
> ConstraintUpdateManager breaks the testcase I previously submitted
> (attachment #2) while persisting initial entities with FK violation
> (against mysql, passes against derby)
It probably doesn't see mysql's keys.
Notice: This email message, together with any attachments, may contain
> It is a matter of having user to specify on @Strategy with a long
> name "
> org.apache.openjpa.jdbc.meta.strats.XMLValueHandler" vs. a shorter
> name.
> "org.apache.openjpa.jdbc.xmlmapping.XMLValueHandler"
Why do they have to specify an explicit strategy at all? Why not
have built-in s
I haven't looked at your code at all, but as an aside, we
consistently use all caps for acronyms in our internal code: JDBC not
Jdbc, URL not Url, and XML not Xml.
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiarie
> The changes in AnnotationPersistenceMappingParser.parseColumns()
> method
> requires JAXB dependency.
Gotcha.
> I can rename openjpa-xmlmapping-5 to openjpa-xmlmapping-jdbc.
> Is this naming acceptable ?
> The org.apache.openjpa.xmlmapping package is also having dependency
> on JAXB.
I ag
> Mike & Patrick,
> I will move the jaxb dependency from kernel to persistence-jdbc.
This doesn't make any sense to me. We have a top-level module for
xml mapping, but it somehow created a JAXB dependency in persistence-
jdbc? How did that happen?
And I agree with Michael Dick's latest comm
[
https://issues.apache.org/jira/browse/OPENJPA-251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12502016
]
Abe White commented on OPENJPA-251:
---
The original implementation used Class.getDeclaredMethod. It was changed
25 matches
Mail list logo
